[jira] [Assigned] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
[
https://issues.apache.org/jira/browse/MESOS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3270:
---
Assignee: haosdent
Fix error GMOCK_CONFIG_CMD in CMake
---
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Assignee: haosdent
The GMOCK_CONFIG_CMD don't contains ${CMAKE_CXX_FLAGS}, this make gmock build
with GTEST_LANG_CXX11 failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2588) Create pre-create hook before a Docker container launches
[ https://issues.apache.org/jira/browse/MESOS-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698301#comment-14698301 ] haosdent commented on MESOS-2588: - ping [~tnachen] Could you review the patch again? Thank you in advance. Create pre-create hook before a Docker container launches - Key: MESOS-2588 URL: https://issues.apache.org/jira/browse/MESOS-2588 Project: Mesos Issue Type: Bug Components: docker Reporter: Timothy Chen Assignee: haosdent To be able to support custom actions to be called before launching a docker contianer, we should create a hook that can be extensible and allow module/hooks to be performed before a docker container is launched. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
[
https://issues.apache.org/jira/browse/MESOS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3270:
Description:
The GMOCK_CONFIG_CMD don't contains $\{CMAKE_CXX_FLAGS\}, this make gmock build
with GTEST_LANG_CXX11 failed.
This bug is report by [~hausdorff] in https://reviews.apache.org/r/37370/
was:The GMOCK_CONFIG_CMD don't contains \$\{CMAKE_CXX_FLAGS\}, this make
gmock build with GTEST_LANG_CXX11 failed.
Fix error GMOCK_CONFIG_CMD in CMake
---
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Assignee: haosdent
The GMOCK_CONFIG_CMD don't contains $\{CMAKE_CXX_FLAGS\}, this make gmock
build with GTEST_LANG_CXX11 failed.
This bug is report by [~hausdorff] in https://reviews.apache.org/r/37370/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
[
https://issues.apache.org/jira/browse/MESOS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3270:
Description: The GMOCK_CONFIG_CMD don't contains \$\{CMAKE_CXX_FLAGS\},
this make gmock build with GTEST_LANG_CXX11 failed. (was: The GMOCK_CONFIG_CMD
don't contains {code}${CMAKE_CXX_FLAGS}{code}, this make gmock build with
GTEST_LANG_CXX11 failed.)
Fix error GMOCK_CONFIG_CMD in CMake
---
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Assignee: haosdent
The GMOCK_CONFIG_CMD don't contains \$\{CMAKE_CXX_FLAGS\}, this make gmock
build with GTEST_LANG_CXX11 failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
haosdent created MESOS-3270:
---
Summary: Fix error GMOCK_CONFIG_CMD in CMake
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
The GMOCK_CONFIG_CMD don't contains ${CMAKE_CXX_FLAGS}, this make gmock build
with GTEST_LANG_CXX11 failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
[
https://issues.apache.org/jira/browse/MESOS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3270:
Description: The GMOCK_CONFIG_CMD don't contains
{code}${CMAKE_CXX_FLAGS}{code}, this make gmock build with GTEST_LANG_CXX11
failed. (was: The GMOCK_CONFIG_CMD don't contains ${CMAKE_CXX_FLAGS}, this
make gmock build with GTEST_LANG_CXX11 failed.)
Fix error GMOCK_CONFIG_CMD in CMake
---
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Assignee: haosdent
The GMOCK_CONFIG_CMD don't contains {code}${CMAKE_CXX_FLAGS}{code}, this make
gmock build with GTEST_LANG_CXX11 failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3270) Fix error GMOCK_CONFIG_CMD in CMake
[
https://issues.apache.org/jira/browse/MESOS-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3270:
Description: The GMOCK_CONFIG_CMD don't contains ${CMAKE_CXX_FLAGS}, this
make gmock build with GTEST_LANG_CXX11 failed. (was: The GMOCK_CONFIG_CMD
don't contains ${CMAKE_CXX_FLAGS}, this make gmock build with GTEST_LANG_CXX11
failed.)
Fix error GMOCK_CONFIG_CMD in CMake
---
Key: MESOS-3270
URL: https://issues.apache.org/jira/browse/MESOS-3270
Project: Mesos
Issue Type: Bug
Reporter: haosdent
Assignee: haosdent
The GMOCK_CONFIG_CMD don't contains ${CMAKE_CXX_FLAGS}, this make gmock
build with GTEST_LANG_CXX11 failed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3247) Add missing unimplemented.hpp to windows specific OS code
haosdent created MESOS-3247: --- Summary: Add missing unimplemented.hpp to windows specific OS code Key: MESOS-3247 URL: https://issues.apache.org/jira/browse/MESOS-3247 Project: Mesos Issue Type: Bug Reporter: haosdent Assignee: haosdent Currently windows specific OS code missing #include stout/unimplemented.hpp. It let compile in windows failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3218) Enhance the bootstrap script
[ https://issues.apache.org/jira/browse/MESOS-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660100#comment-14660100 ] gyliu commented on MESOS-3218: -- The bootstrap is only for developers and it is not suggested to run ln -s xx xx manually by developer. Enhance the bootstrap script Key: MESOS-3218 URL: https://issues.apache.org/jira/browse/MESOS-3218 Project: Mesos Issue Type: Improvement Reporter: Chen Zhiwei Assignee: Chen Zhiwei Priority: Trivial Running bootstrap command in Mesos root directory will create some link files. But it can't handle below case: 1. Users accidently create an invalid link file $ ln -s .gitignore-templat .gitignore 2. Then running bootstrap command will show an error message $ ./bootstrap ln: failed to create symbolic link ‘.gitignore’: File exists The `test -e` command can't recognize invalid link file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2337) __init__.py not getting installed in $PREFIX/lib/pythonX.Y/site-packages/mesos
[
https://issues.apache.org/jira/browse/MESOS-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653859#comment-14653859
]
haosdent commented on MESOS-2337:
-
Refrence openstack, them have
/usr/lib/python2.7/dist-packages/openstack/__init__.py under [common
module|http://packages.ubuntu.com/zh-cn/precise/amd64/python-openstack-common/filelist],
and other [sub
module|http://packages.ubuntu.com/zh-cn/precise/amd64/python-openstack-compute/filelist]
don't contains this.
__init__.py not getting installed in $PREFIX/lib/pythonX.Y/site-packages/mesos
--
Key: MESOS-2337
URL: https://issues.apache.org/jira/browse/MESOS-2337
Project: Mesos
Issue Type: Bug
Components: build, python api
Reporter: Kapil Arya
Assignee: Marco Massenzio
Priority: Critical
Labels: mesosphere
When doing a {{make install}}, the src/python/native/src/mesos/__init__.py
file is not getting installed in
{{$PREFIX/lib/pythonX.Y/site-packages/mesos/}}.
This makes it impossible to do the following import when {{PYTHONPATH}} is
set to the {{site-packages}} directory.
{code}
import mesos.interface.mesos_pb2
{code}
The directories {{$PREFIX/lib/pythonX.Y/site-packages/mesos/interface,
native}} do have their corresponding {{__init__.py}} files.
Reproducing the bug:
{code}
../configure --prefix=$HOME/test-install make install
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (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-tabpanelfocusedCommentId=14645670#comment-14645670
]
haosdent edited comment on MESOS-3141 at 8/6/15 7:56 AM:
-
I also submit a simple patch to rbt, let it support binary file.
https://github.com/reviewboard/rbtools/pull/50/files
was (Author: haosd...@gmail.com):
The pull request in Github. https://github.com/apache/mesos/pull/50/files
Contains binary changes. [~mcypark]
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_casttypename remove_referenceT::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::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::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::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(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::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : 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_casttypename remove_referenceT::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 typename T
T Invalid() {
return *static_casttypename remove_referenceT::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 type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr
[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-tabpanelfocusedCommentId=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-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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_casttypename remove_referenceT::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::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::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::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(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::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : 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_casttypename remove_referenceT::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 typename T
T Invalid() {
return *static_casttypename remove_referenceT::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 type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{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
[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] [Commented] (MESOS-3081) Default configuration of google logging
[ https://issues.apache.org/jira/browse/MESOS-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] [Created] (MESOS-3149) Use setuptools to install python cli package
haosdent created MESOS-3149:
---
Summary: Use setuptools to install python cli package
Key: MESOS-3149
URL: https://issues.apache.org/jira/browse/MESOS-3149
Project: Mesos
Issue Type: Task
Reporter: haosdent
Assignee: haosdent
mesos-ps/mesos-cat which depends on src/cli/python/mesos could not work in OSX
because src/cli/python is not installed to sys.path. It's time to finish this
TODO.
{code}
# Add 'src/cli/python' to PYTHONPATH.
# TODO(benh): Remove this if/when we install the 'mesos' module via
# PIP and setuptools.
PYTHONPATH=@abs_top_srcdir@/src/cli/python:${PYTHONPATH}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation
[ https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642028#comment-14642028 ] haosdent commented on MESOS-3139: - Got it. Looking forward CMake and running mesos in windows! Incorporate CMake into standard documentation - Key: MESOS-3139 URL: https://issues.apache.org/jira/browse/MESOS-3139 Project: Mesos Issue Type: Task Components: build Reporter: Alex Clemmer Assignee: Alex Clemmer Labels: build, cmake, mesosphere Right now it's anyone's guess how to build with CMake. If we want people to use it, we should put up documentation. The central challenge is that the CMake instructions will be slightly different for different platforms. For example, on Linux, the gist of the build is basically the same as autotools; you pull down the system dependencies (like APR, _etc_.), and then: ``` ./bootstrap mkdir build-cmake cd build-cmake cmake .. make ``` But, on Windows, it will be somewhat more complicated. There is no bootstrap step, for example, because Windows doesn't have bash natively. And even when we put that in, you'll still have to build the glog stuff out-of-band because CMake has no way of booting up Visual Studio and calling build. So practically, we need to figure out: * What our build story is for different platforms * Write specific instructions for our core target platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3111) Executor Process gets killed before executor_shutdown_grace_period
[
https://issues.apache.org/jira/browse/MESOS-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642202#comment-14642202
]
haosdent commented on MESOS-3111:
-
{code}
class ShutdownProcess : public ProcessShutdownProcess
{
protected:
virtual void initialize()
{
VLOG(1) Scheduling shutdown of the executor;
// TODO(benh): Pass the shutdown timeout with ExecutorRegistered
// since it might have gotten configured on the command line.
delay(slave::EXECUTOR_SHUTDOWN_GRACE_PERIOD, self(), Self::kill);
}
{code}
{code}
void shutdown()
{
if (aborted) {
VLOG(1) Ignoring shutdown message because the driver is aborted!;
return;
}
LOG(INFO) Executor asked to shutdown;
if (!local) {
// Start the Shutdown Process.
spawn(new ShutdownProcess(), true);
}
{code}
And slave::EXECUTOR_SHUTDOWN_GRACE_PERIOD is default 5 seconds.
Executor Process gets killed before executor_shutdown_grace_period
--
Key: MESOS-3111
URL: https://issues.apache.org/jira/browse/MESOS-3111
Project: Mesos
Issue Type: Bug
Components: framework
Affects Versions: 0.22.1
Environment: OS X 10.10.3
Reporter: Rajesh Kumar
I am starting mesos slave with following command:
./bin/mesos-slave.sh --master=zk://127.0.0.1:2181/global
--work_dir=/mnt1/logs/mesos/ --executor_registration_timeout=3mins
--executor_shutdown_grace_period=60secs
As you see I have specified executor_shutdown_grace_period as 60 sec. When
framework is shutdown it is expected that executors process will be shutdown
gracefully. If executor takes longer than executor_shutdown_grace_period, it
will be killed by SIGKILL. But it seems its not happening as expected.
Looking at following slave log, request to shutdown comes around 14:55:25 and
executor is killed with SIGKILL at 14:55:30, just 5 secs later. I was
expecting it to wait till 60 secs.
I0721 14:55:14.430140 178049024 slave.cpp:2164] Got registration for executor
'global' of framework global_2015-07-21_09-23-57_542 from
executor(1)@172.16.20.211:62623
I0721 14:55:14.432839 178049024 slave.cpp:1555] Sending queued task
'Long_Running_Job 0' to executor 'global' of framework
global_2015-07-21_09-23-57_542
I0721 14:55:23.275876 176975872 slave.cpp:3648] Current disk usage 36.83%.
Max allowed age: 3.721608945021898days
I0721 14:55:25.493098 180195328 slave.cpp:1768] Asked to shut down framework
global_2015-07-21_09-23-57_542 by master@127.0.0.1:5050
I0721 14:55:25.493131 180195328 slave.cpp:1793] Shutting down framework
global_2015-07-21_09-23-57_542
I0721 14:55:25.493176 180195328 slave.cpp:3473] Shutting down executor
'global' of framework global_2015-07-21_09-23-57_542
I0721 14:55:30.514751 179658752 containerizer.cpp:1123] Executor for
container 'de9f1d01-bbb6-4fbe-b41b-2a253498d6a1' has exited
I0721 14:55:30.514798 179658752 containerizer.cpp:918] Destroying container
'de9f1d01-bbb6-4fbe-b41b-2a253498d6a1'
I0721 14:55:30.538887 177512448 slave.cpp:3223] Executor 'global' of
framework global_2015-07-21_09-23-57_542 terminated with signal Killed: 9
--
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-tabpanelfocusedCommentId=14642221#comment-14642221
]
haosdent commented on MESOS-3141:
-
I update gmock to 1.7.0
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_casttypename remove_referenceT::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::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::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::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(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::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : 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_casttypename remove_referenceT::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 typename T
T Invalid() {
return *static_casttypename remove_referenceT::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 type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{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
{{Futurevoid
[jira] [Assigned] (MESOS-3111) Executor Process gets killed before executor_shutdown_grace_period
[ https://issues.apache.org/jira/browse/MESOS-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3111: --- Assignee: haosdent Executor Process gets killed before executor_shutdown_grace_period -- Key: MESOS-3111 URL: https://issues.apache.org/jira/browse/MESOS-3111 Project: Mesos Issue Type: Bug Components: framework Affects Versions: 0.22.1 Environment: OS X 10.10.3 Reporter: Rajesh Kumar Assignee: haosdent I am starting mesos slave with following command: ./bin/mesos-slave.sh --master=zk://127.0.0.1:2181/global --work_dir=/mnt1/logs/mesos/ --executor_registration_timeout=3mins --executor_shutdown_grace_period=60secs As you see I have specified executor_shutdown_grace_period as 60 sec. When framework is shutdown it is expected that executors process will be shutdown gracefully. If executor takes longer than executor_shutdown_grace_period, it will be killed by SIGKILL. But it seems its not happening as expected. Looking at following slave log, request to shutdown comes around 14:55:25 and executor is killed with SIGKILL at 14:55:30, just 5 secs later. I was expecting it to wait till 60 secs. I0721 14:55:14.430140 178049024 slave.cpp:2164] Got registration for executor 'global' of framework global_2015-07-21_09-23-57_542 from executor(1)@172.16.20.211:62623 I0721 14:55:14.432839 178049024 slave.cpp:1555] Sending queued task 'Long_Running_Job 0' to executor 'global' of framework global_2015-07-21_09-23-57_542 I0721 14:55:23.275876 176975872 slave.cpp:3648] Current disk usage 36.83%. Max allowed age: 3.721608945021898days I0721 14:55:25.493098 180195328 slave.cpp:1768] Asked to shut down framework global_2015-07-21_09-23-57_542 by master@127.0.0.1:5050 I0721 14:55:25.493131 180195328 slave.cpp:1793] Shutting down framework global_2015-07-21_09-23-57_542 I0721 14:55:25.493176 180195328 slave.cpp:3473] Shutting down executor 'global' of framework global_2015-07-21_09-23-57_542 I0721 14:55:30.514751 179658752 containerizer.cpp:1123] Executor for container 'de9f1d01-bbb6-4fbe-b41b-2a253498d6a1' has exited I0721 14:55:30.514798 179658752 containerizer.cpp:918] Destroying container 'de9f1d01-bbb6-4fbe-b41b-2a253498d6a1' I0721 14:55:30.538887 177512448 slave.cpp:3223] Executor 'global' of framework global_2015-07-21_09-23-57_542 terminated with signal Killed: 9 -- 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-tabpanelfocusedCommentId=14642241#comment-14642241
]
haosdent commented on MESOS-3141:
-
LoL. [~mcypark] Seems review board not support binary data. Should I submit
through github pull request?
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_casttypename remove_referenceT::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::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::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::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(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::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : 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_casttypename remove_referenceT::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 typename T
T Invalid() {
return *static_casttypename remove_referenceT::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 type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{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
[jira] [Commented] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
[ https://issues.apache.org/jira/browse/MESOS-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642343#comment-14642343 ] haosdent commented on MESOS-3091: - I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it maybe override exists headers. Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory --- Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed ElTahan When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3087) Typos in oversubscription doc
[
https://issues.apache.org/jira/browse/MESOS-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642319#comment-14642319
]
haosdent commented on MESOS-3087:
-
Patch: https://reviews.apache.org/r/36839/
Typos in oversubscription doc
-
Key: MESOS-3087
URL: https://issues.apache.org/jira/browse/MESOS-3087
Project: Mesos
Issue Type: Documentation
Components: documentation
Affects Versions: 0.23.0
Reporter: Brian Candler
Priority: Trivial
Labels: newbie
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is
done through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will
have the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3087) Typos in oversubscription doc
[
https://issues.apache.org/jira/browse/MESOS-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3087:
---
Assignee: haosdent
Typos in oversubscription doc
-
Key: MESOS-3087
URL: https://issues.apache.org/jira/browse/MESOS-3087
Project: Mesos
Issue Type: Documentation
Components: documentation
Affects Versions: 0.23.0
Reporter: Brian Candler
Assignee: haosdent
Priority: Trivial
Labels: newbie
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is
done through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will
have the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
[ https://issues.apache.org/jira/browse/MESOS-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642343#comment-14642343 ] haosdent edited comment on MESOS-3091 at 7/27/15 6:39 AM: -- I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it may override exists headers. was (Author: haosd...@gmail.com): I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it maybe override exists headers. Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory --- Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed ElTahan When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [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-tabpanelfocusedCommentId=14642056#comment-14642056
]
haosdent commented on MESOS-3126:
-
{code}
[ERROR] Java heap space - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError
{code}
The problem for this is because no enough memory.
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-tabpanelfocusedCommentId=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)
[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] [Commented] (MESOS-3139) Incorporate CMake into standard documentation
[ https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640884#comment-14640884 ] haosdent commented on MESOS-3139: - @hausdorff Got it thank you. Incorporate CMake into standard documentation - Key: MESOS-3139 URL: https://issues.apache.org/jira/browse/MESOS-3139 Project: Mesos Issue Type: Task Components: build Reporter: Alex Clemmer Assignee: Alex Clemmer Labels: build, cmake, mesosphere Right now it's anyone's guess how to build with CMake. If we want people to use it, we should put up documentation. The central challenge is that the CMake instructions will be slightly different for different platforms. For example, on Linux, the gist of the build is basically the same as autotools; you pull down the system dependencies (like APR, _etc_.), and then: ``` ./bootstrap mkdir build-cmake cd build-cmake cmake .. make ``` But, on Windows, it will be somewhat more complicated. There is no bootstrap step, for example, because Windows doesn't have bash natively. And even when we put that in, you'll still have to build the glog stuff out-of-band because CMake has no way of booting up Visual Studio and calling build. So practically, we need to figure out: * What our build story is for different platforms * Write specific instructions for our core target platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3098) Implement WindowsContainerizer and WindowsDockerContainerizer
[ https://issues.apache.org/jira/browse/MESOS-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14641595#comment-14641595 ] haosdent edited comment on MESOS-3098 at 7/25/15 1:55 PM: -- Is WindowsContainer a Linux actually? Or windows container is a windows and only could run windows program? was (Author: haosd...@gmail.com): Does WindowsContainer is a Linux actually? Or windows container is a windows and only could run windows program? Implement WindowsContainerizer and WindowsDockerContainerizer - Key: MESOS-3098 URL: https://issues.apache.org/jira/browse/MESOS-3098 Project: Mesos Issue Type: Task Components: containerization Reporter: Joseph Wu Assignee: Alex Clemmer Labels: mesosphere The MVP for Windows support is a containerizer that (1) runs on Windows, and (2) runs and passes all the tests that are relevant to the Windows platform (_e.g._, not the tests that involve cgroups). To do this we require at least a `WindowsContainerizer` (to be implemented alongside the `MesosContainerizer`), which provides no meaningful (_e.g._) process namespacing (much like the default unix containerizer). In the long term (hopefully before MesosCon) we want to support also the Windows container API. This will require implementing a separate containerizer, maybe called `WindowsDockerContainerizer`. Since the Windows container API is actually officially supported through the Docker interface (_i.e._, MSFT actually ported the Docker engine to Windows, and that is the official API), the interfaces (like the fetcher) shouldn't change much. The tests probably will have to change, as we don't have access to any isolation primitives like cgroups for those tests. Outstanding TODO([~hausdorff]): Flesh out this description when more details are available, regarding: * The container API for Windows (when we know them) * The nuances of Windows vs Linux (when we know them) * etc. -- 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-tabpanelfocusedCommentId=14641651#comment-14641651 ] haosdent commented on MESOS-527: Patch: https://reviews.apache.org/r/36814/ I use executor in mesos-execute directly. [~bmahler] Does this way acceptable? 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 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-2411) trailing slash in work_dir causes sandbox link issues
[ https://issues.apache.org/jira/browse/MESOS-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14641494#comment-14641494 ] haosdent commented on MESOS-2411: - Could not reproduce this problem in 0.23. Please check again [~elmalto] trailing slash in work_dir causes sandbox link issues - Key: MESOS-2411 URL: https://issues.apache.org/jira/browse/MESOS-2411 Project: Mesos Issue Type: Bug Components: webui Affects Versions: 0.20.1 Reporter: Malte Buecken Assignee: haosdent Priority: Trivial Original Estimate: 1h Remaining Estimate: 1h OS: Debian (wheezy-backports 7) When you define a work_dir and the work_dir has a trailing /, you cannot open the sandbox in the webui any more because of two // in the url which produce a angular.js parse error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3040) Update submitting-a-patch.md
[ https://issues.apache.org/jira/browse/MESOS-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14625750#comment-14625750 ] gyliu commented on MESOS-3040: -- The step 7 in submitting a patch is: Make your changes to the code (using whatever IDE/editor you choose) to actually fix the bug or implement the feature. Before beginning, please read the Mesos C++ Style Guide. It is recommended to use the git pre-commit hook (support/hooks/pre-commit) to automatically check for style errors. See the hook script for instructions to enable it. Most of your changes will probably be to files inside of BASE_MESOS_DIR To build, we recommend that you don’t build inside of the src directory. We recommend you do the following: From inside of the root Mesos directory: mkdir build cd build ../configure make Now all of the files generated by the build process will be contained in the build directory you created, instead of being spread throughout the src directory, which is a bit messier. This is both cleaner, and makes it easy to clean up if you want to get rid of the files generated by configure and make. I.e. You can reset your build process without risking changes you made in the src directory, by simply deleting the build directory, and creating a new one. Make sure all of your test cases now pass. The build instructions in getting start is: # Change working directory. $ cd mesos # Bootstrap (Only required if building from git repository). $ ./bootstrap # Configure and build. $ mkdir build $ cd build $ ../configure $ make IMHO, the getting started can give some command to enable one can get a quick start, but the submitting a patch should add more detail for what the command does and why we want to do that. Update submitting-a-patch.md Key: MESOS-3040 URL: https://issues.apache.org/jira/browse/MESOS-3040 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 1.0.0 Reporter: gyliu Assignee: gyliu Fix For: 1.0.0 When developer is using git to clone the mesos source code and want to build, s/he need to run ./bootstrap first to generate some files such as configure, .gitignore etc. But the document do not including such instructions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3040) Update submitting-a-patch.md
gyliu created MESOS-3040: Summary: Update submitting-a-patch.md Key: MESOS-3040 URL: https://issues.apache.org/jira/browse/MESOS-3040 Project: Mesos Issue Type: Documentation Components: documentation Affects Versions: 1.0.0 Reporter: gyliu Fix For: 1.0.0 When developer is using git to clone the mesos source code and want to build, s/he need to run ./bootstrap first to generate some files such as configure, .gitignore etc. But the document do not including such instructions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3059) Allow http endpoint to dynamically change the slave attributes
[ https://issues.apache.org/jira/browse/MESOS-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin updated MESOS-3059: - Description: This is well understood that - changing the attributes dynamically is not safe without a restart because slave itself may not know which old framework tasks are running on it that were dependent on previous attributes. However, total restart makes lot of other history to delete. We need to ensure a dynamic attribute changes with a soft restart. It will be good to expose a rest endpoint either at slave or mesos-master which directly changes the state in zookeeper. USE-CASE We use slave attributes/roles to direct the framework scheduling to use specific slave as per it's requirements. Mesos scheduler only creates the offer on the basis of some resources. In our use case, we have some categorization of our spark frameworks or jobs with framework(like marathon) based on multiple factors. We want job or frameworks belonging to one category be running into their specific cluster of resources. We want to dynamically manage the slaves into these logical sub-clusters. Since number of jobs that will be submitted or when it will be submitted is very dynamic, it make sense to be able to dynamically assign roles or attributes to slaves. It is not possible to gauge the requirements at time of cluster provisioning. Static role or attribute assignment leads to sub-optimal use of the cluster. was: This is well understood that - changing the attributes dynamically is not safe without a restart because slave itself may not know which old framework tasks are running on it that were dependent on previous attributes. However, total restart makes lot of other history to delete. We need to ensure a dynamic attribute changes with a soft restart. It will be good to expose a rest endpoint either at slave or mesos-master which directly changes the state in zookeeper. USE-CASE We use slave attributes/roles to direct the framework scheduling to use specific slave as per it's requirements. Mesos scheduler only creates the offer on the basis of some resources. In our use case, we have some categorization of our spark frameworks or jobs with framework(like marathon) based on multiple factors. We want job or frameworks belonging to one category be running into their specific cluster of resources. We want to dynamically manage the slaves into these logical sub-clusters. Allow http endpoint to dynamically change the slave attributes -- Key: MESOS-3059 URL: https://issues.apache.org/jira/browse/MESOS-3059 Project: Mesos Issue Type: Wish Reporter: Nitin This is well understood that - changing the attributes dynamically is not safe without a restart because slave itself may not know which old framework tasks are running on it that were dependent on previous attributes. However, total restart makes lot of other history to delete. We need to ensure a dynamic attribute changes with a soft restart. It will be good to expose a rest endpoint either at slave or mesos-master which directly changes the state in zookeeper. USE-CASE We use slave attributes/roles to direct the framework scheduling to use specific slave as per it's requirements. Mesos scheduler only creates the offer on the basis of some resources. In our use case, we have some categorization of our spark frameworks or jobs with framework(like marathon) based on multiple factors. We want job or frameworks belonging to one category be running into their specific cluster of resources. We want to dynamically manage the slaves into these logical sub-clusters. Since number of jobs that will be submitted or when it will be submitted is very dynamic, it make sense to be able to dynamically assign roles or attributes to slaves. It is not possible to gauge the requirements at time of cluster provisioning. Static role or attribute assignment leads to sub-optimal use of the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3023) Factoring out the pattern for URL generation
[ https://issues.apache.org/jira/browse/MESOS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14630891#comment-14630891 ] haosdent commented on MESOS-3023: - Hi, [~klaus1982] Thank you for your patch, I also write some new review to it. Maybe you need find a committer to shepherd this. Because a shepherd committer could give you more advice and help you to commit it. :-) And IMHO, if this pattern only use in this one place, do we still need factoring out the pattern? Or waiting some other places also need use this pattern, and generic it at that time? Factoring out the pattern for URL generation - Key: MESOS-3023 URL: https://issues.apache.org/jira/browse/MESOS-3023 Project: Mesos Issue Type: Task Reporter: Artem Harutyunyan Assignee: Klaus Ma Priority: Minor Labels: beginner, mesosphere, newbie fetcher_test.cpp uses the following code for generating URLs: string url = http://; + net::getHostname(process.self().address.ip).get() + : + stringify(process.self().address.port) + / + process.self().id it would be good to isolate that code in a function, and replace the code above with something like: string url = http://; + endpoint_url(process, uri_test); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
Mohamed created MESOS-3091: -- Summary: Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3706) Tasks stuck in staging.
[
https://issues.apache.org/jira/browse/MESOS-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966818#comment-14966818
]
haosdent commented on MESOS-3706:
-
As you stay, stdout and stderr are empty. Could you try use strace or gdb to
attach the mesos-docker-executor hangout which point? For example, in the
example you describe in description, try use
{noformat}
strace -p 35360
{noformat}
to find mesos-docker-executor blocks on which syscall and then post result here.
> Tasks stuck in staging.
> ---
>
> Key: MESOS-3706
> URL: https://issues.apache.org/jira/browse/MESOS-3706
> Project: Mesos
> Issue Type: Bug
> Components: docker, slave
>Affects Versions: 0.23.0, 0.24.1
>Reporter: Jord Sonneveld
> Attachments: Screen Shot 2015-10-12 at 9.08.30 AM.png, Screen Shot
> 2015-10-12 at 9.24.32 AM.png, docker.txt, mesos-slave.INFO,
> mesos-slave.INFO.2, mesos-slave.INFO.3, stderr, stdout
>
>
> I have a docker image which starts fine on all my slaves except for one. On
> that one, it is stuck in STAGING for a long time and never starts. The INFO
> log is full of messages like this:
> I1012 16:02:09.210306 34905 slave.cpp:1768] Asked to kill task
> kwe-vinland-work.6c939697-70f8-11e5-845c-0242e054dd72 of framework
> 20150109-172016-504433162-5050-19367-0002
> E1012 16:02:09.211272 34907 socket.hpp:174] Shutdown failed on fd=12:
> Transport endpoint is not connected [107]
> kwe-vinland-work is the task that is stuck in staging. It is launched by
> marathon. I have launched 161 instances successfully on my cluster. But it
> refuses to launch on this specific slave.
> These machines are all managed via ansible so their configurations are /
> should be identical. I have re-run my ansible scripts and rebooted the
> machines to no avail.
> It's been in this state for almost 30 minutes. You can see the mesos docker
> executor is still running:
> jord@dalstgmesos03:~$ date
> Mon Oct 12 16:13:55 UTC 2015
> jord@dalstgmesos03:~$ ps auwx | grep kwe-vinland
> root 35360 0.0 0.0 1070576 21476 ? Ssl 15:46 0:00
> mesos-docker-executor
> --container=mesos-20151012-082619-4145023498-5050-22623-S0.0695c9e0-0adf-4dfb-bc2a-6060245dcabe
> --docker=docker --help=false --mapped_directory=/mnt/mesos/sandbox
> --sandbox_directory=/data/mesos/mesos/work/slaves/20151012-082619-4145023498-5050-22623-S0/frameworks/20150109-172016-504433162-5050-19367-0002/executors/kwe-vinland-work.6c939697-70f8-11e5-845c-0242e054dd72/runs/0695c9e0-0adf-4dfb-bc2a-6060245dcabe
> --stop_timeout=0ns
> According to docker ps -a, nothing was ever even launched:
> jord@dalstgmesos03:/data/mesos$ sudo docker ps -a
> CONTAINER IDIMAGE
> COMMAND CREATED STATUS PORTS
> NAMES
> 5c858b90b0a0registry.roger.dal.moz.com:5000/moz-statsd-v0.22
> "/bin/sh -c ./start.s" 39 minutes ago Up 39 minutes
> 0.0.0.0:9125->8125/udp, 0.0.0.0:9126->8126/tcp statsd-fe-influxdb
> d765ba3829fdregistry.roger.dal.moz.com:5000/moz-statsd-v0.22
> "/bin/sh -c ./start.s" 41 minutes ago Up 41 minutes
> 0.0.0.0:8125->8125/udp, 0.0.0.0:8126->8126/tcp statsd-repeater
> Those are the only two entries. Nothing about the kwe-vinland job.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1582) Improve build time.
[ https://issues.apache.org/jira/browse/MESOS-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14972825#comment-14972825 ] haosdent commented on MESOS-1582: - Add the missing libprocess build time for every object: http://fpaste.org/283318/ > Improve build time. > --- > > Key: MESOS-1582 > URL: https://issues.apache.org/jira/browse/MESOS-1582 > Project: Mesos > Issue Type: Epic > Components: build >Reporter: Benjamin Hindman > > The build takes a ridiculously long time unless you have a large, parallel > machine. This is a combination of many factors, all of which we'd like to > discuss and track here. > I'd also love to actually track build times so we can get an appreciation of > the improvements. Please leave a comment below with your build times! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971183#comment-14971183
]
haosdent commented on MESOS-3793:
-
Please add --launcher=posix or mount cgroup as rw when launch docker container.
http://search-hadoop.com/m/0Vlr6zfCev1S7gRF1
> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
> Labels: mesosphere
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485 136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302 136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343 136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355 136 leveldb.cpp:204] Seeked to beginning of db in
> 1287ns
> I1022 18:42:26.853366 136 leveldb.cpp:273] Iterated through 0 keys in the
> db in ns
> I1022 18:42:26.853406 136 replica.cpp:744] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775 141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862 141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751 138 replica.cpp:641] Replica in EMPTY status received
> a broadcasted recover request
> I1022 18:42:26.854856 140 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1022 18:42:26.855002 140 recover.cpp:566] Updating replica status to
> STARTING
> I1022 18:42:26.855655 138 master.cpp:376] Master
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on
> 172.17.0.14:5050
> I1022 18:42:26.855680 138 master.cpp:378] Flags at startup:
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="false" --authenticate_slaves="false"
> --authenticators="crammd5" --authorizers="local" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --initialize_driver_logging="true"
> --log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO"
> --max_slave_ping_timeouts="5" --quiet="false"
> --recovery_slave_removal_limit="100%" --registry="replicated_log"
> --registry_fetch_timeout="1mins" --registry_store_timeout="5secs"
> --registry_strict="false" --root_submissions="true"
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins"
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui"
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790 138 master.cpp:425] Master allowing unauthenticated
> frameworks to register
> I1022 18:42:26.855803 138 master.cpp:430] Master allowing unauthenticated
> slaves to register
> I1022 18:42:26.855815 138 master.cpp:467] Using default 'crammd5'
> authenticator
> W1022 18:42:26.855829 138 authenticator.cpp:505] No credentials provided,
> authentication requests will be refused
> I1022 18:42:26.855840 138 authenticator.cpp:512] Initializing server SASL
> I1022 18:42:26.856442 136 containerizer.cpp:143] Using isolation:
> posix/cpu,posix/mem,filesystem/posix
> I1022 18:42:26.856943 140 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.888185ms
> I1022 18:42:26.856987 140 replica.cpp:323] Persisted replica status to
> STARTING
> I1022 18:42:26.857115 140 recover.cpp:475] Replica is in STARTING status
> I1022 18:42:26.857270 140 replica.cpp:641] Replica in STARTING status
> received a broadcasted recover request
> I1022 18:42:26.857312 140 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1022 18:42:26.857368 140 recover.cpp:566] Updating replica status to VOTING
> I1022 18:42:26.857781 140 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 371121ns
> I1022 18:42:26.857841 140 replica.cpp:323] Persisted replica status to
> VOTING
> I1022 18:42:26.857895 140 recover.cpp:580] S
[jira] [Commented] (MESOS-1582) Improve build time.
[ https://issues.apache.org/jira/browse/MESOS-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973107#comment-14973107 ] haosdent commented on MESOS-1582: - I found most time are spent in #include files. For example, #include "tests/mesos.hpp" need 3 seconds, #include "master/master.hpp" also nearly 3 seconds. I would write a script to generate a list contains the include time for every header file. > Improve build time. > --- > > Key: MESOS-1582 > URL: https://issues.apache.org/jira/browse/MESOS-1582 > Project: Mesos > Issue Type: Epic > Components: build >Reporter: Benjamin Hindman > > The build takes a ridiculously long time unless you have a large, parallel > machine. This is a combination of many factors, all of which we'd like to > discuss and track here. > I'd also love to actually track build times so we can get an appreciation of > the improvements. Please leave a comment below with your build times! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3506) Build instructions for CentOS 6.6 should include `sudo yum update`
[
https://issues.apache.org/jira/browse/MESOS-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971413#comment-14971413
]
haosdent commented on MESOS-3506:
-
I test this in CentOS 6 docker image, seem don't contains default
{noformat}
[root@af15e2315ea4 /]# wget
bash: wget: command not found
[root@af15e2315ea4 /]# tar
bash: tar: command not found
[root@af15e2315ea4 /]# which
bash: which: command not found
[root@af15e2315ea4 /]# cat /etc/issue
CentOS release 6.7 (Final)
Kernel \r on an \m
{noformat}
> Build instructions for CentOS 6.6 should include `sudo yum update`
> --
>
> Key: MESOS-3506
> URL: https://issues.apache.org/jira/browse/MESOS-3506
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.25.0
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: documentation, mesosphere
>
> Neglecting to run {{sudo yum update}} on CentOS 6.6 currently causes the
> build to break when building {{mesos-0.25.0.jar}}. The build instructions for
> this platform on the Getting Started page should be changed accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3545) Investigate restoring tasks/executors after machine reboot.
[ https://issues.apache.org/jira/browse/MESOS-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14969497#comment-14969497 ] Megha commented on MESOS-3545: -- Here's the first draft of the design for Persistent Tasks. Looking forward to feedback and comments. https://docs.google.com/document/d/1l7goeISpYmCjM03l20lmjZ6_BMfdxBs31znEBRtzsuU/edit?usp=sharing > Investigate restoring tasks/executors after machine reboot. > --- > > Key: MESOS-3545 > URL: https://issues.apache.org/jira/browse/MESOS-3545 > Project: Mesos > Issue Type: Improvement > Components: slave >Reporter: Benjamin Hindman > Labels: mesosphere > > If a task/executor is restartable (see MESOS-3544) it might make sense to > force an agent to restart these tasks/executors _before_ after a machine > reboot in the event that the machine is network partitioned away from the > master (or the master has failed) but we'd like to get these services running > again. Assuming the agent(s) running on the machine has not been disconnected > from the master for longer than the master's agent re-registration timeout > the agent should be able to re-register (i.e., after a network partition is > resolved) without a problem. However, in the same way that a framework would > be interested in knowing that it's tasks/executors were restarted we'd want > to send something like a TASK_RESTARTED status update. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[ https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975836#comment-14975836 ] haosdent commented on MESOS-3787: - Add a test case to verify above proposal could works. https://reviews.apache.org/r/39678/ > As a developer, I'd like to be able to expand environment variables through > the Docker executor. > > > Key: MESOS-3787 > URL: https://issues.apache.org/jira/browse/MESOS-3787 > Project: Mesos > Issue Type: Wish >Reporter: John Garcia > Labels: mesosphere > Attachments: mesos.patch, test-example.json > > > We'd like to have expanded variables usable in [the json files used to create > a Marathon app, hence] the Task's CommandInfo, so that the executor is able > to detect the correct values at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[
https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975486#comment-14975486
]
haosdent commented on MESOS-3787:
-
I think we just need run it use the shell way, not need extra variables before
start.
{node}
diff --git a/src/docker/docker.cpp b/src/docker/docker.cpp
index 56d63dc..71327bd 100755
--- a/src/docker/docker.cpp
+++ b/src/docker/docker.cpp
@@ -583,8 +583,7 @@ Future Docker::run(
}
Try s = subprocess(
- path,
- argv,
+ cmd,
Subprocess::PATH("/dev/null"),
stdoutIo,
stderrIo,
{node}
According my test example in https://reviews.apache.org/r/39387/ . Pass "$xxx"
would replace to environment variables when running.
> As a developer, I'd like to be able to expand environment variables through
> the Docker executor.
>
>
> Key: MESOS-3787
> URL: https://issues.apache.org/jira/browse/MESOS-3787
> Project: Mesos
> Issue Type: Wish
>Reporter: John Garcia
> Labels: mesosphere
> Attachments: mesos.patch, test-example.json
>
>
> We'd like to have expanded variables usable in [the json files used to create
> a Marathon app, hence] the Task's CommandInfo, so that the executor is able
> to detect the correct values at runtime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[
https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975486#comment-14975486
]
haosdent edited comment on MESOS-3787 at 10/27/15 1:28 AM:
---
I think we just need run it use the shell way, not need extra variables before
start.
{code}
diff --git a/src/docker/docker.cpp b/src/docker/docker.cpp
index 56d63dc..71327bd 100755
--- a/src/docker/docker.cpp
+++ b/src/docker/docker.cpp
@@ -583,8 +583,7 @@ Future Docker::run(
}
Try s = subprocess(
- path,
- argv,
+ cmd,
Subprocess::PATH("/dev/null"),
stdoutIo,
stderrIo,
{code}
According my test example in https://reviews.apache.org/r/39387/ . Pass "$xxx"
would replace to environment variables when running.
was (Author: haosd...@gmail.com):
I think we just need run it use the shell way, not need extra variables before
start.
{node}
diff --git a/src/docker/docker.cpp b/src/docker/docker.cpp
index 56d63dc..71327bd 100755
--- a/src/docker/docker.cpp
+++ b/src/docker/docker.cpp
@@ -583,8 +583,7 @@ Future Docker::run(
}
Try s = subprocess(
- path,
- argv,
+ cmd,
Subprocess::PATH("/dev/null"),
stdoutIo,
stderrIo,
{node}
According my test example in https://reviews.apache.org/r/39387/ . Pass "$xxx"
would replace to environment variables when running.
> As a developer, I'd like to be able to expand environment variables through
> the Docker executor.
>
>
> Key: MESOS-3787
> URL: https://issues.apache.org/jira/browse/MESOS-3787
> Project: Mesos
> Issue Type: Wish
>Reporter: John Garcia
> Labels: mesosphere
> Attachments: mesos.patch, test-example.json
>
>
> We'd like to have expanded variables usable in [the json files used to create
> a Marathon app, hence] the Task's CommandInfo, so that the executor is able
> to detect the correct values at runtime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2635) Web UI Display Bug when starting lots of tasks with small cpu value
[ https://issues.apache.org/jira/browse/MESOS-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975492#comment-14975492 ] haosdent edited comment on MESOS-2635 at 10/27/15 1:34 AM: --- Seems I could not found values depends on metrics in frameworks.html and framework.html. Could you provide more details about this? Last time I found only slave and master pages depends on values have to got from metrics endpoint, so I only update them. was (Author: haosd...@gmail.com): Seems I could not found values depends on metrics in frameworks.html Could you provide more details about this? Last time I found only slave and master pages depends on values have to got from metrics endpoint, so I only update them. > Web UI Display Bug when starting lots of tasks with small cpu value > --- > > Key: MESOS-2635 > URL: https://issues.apache.org/jira/browse/MESOS-2635 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.22.0 >Reporter: Lukas Loesche >Assignee: haosdent >Priority: Minor > Fix For: 0.25.0 > > Attachments: Screen Shot 2015-04-17 at 18.53.54.png, fixed_after.png, > fixed_before.png > > > During Marathon scale testing we encountered a display bug where the Mesos > Web UI would show -4.064304448547773e-11 Idle CPUs in the Resources overview. > To reproduce, we started: > "cmd": "python -m SimpleHTTPServer $PORT0", > "cpus": 0.0001, > "instances": 2000, > "mem": 32, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2635) Web UI Display Bug when starting lots of tasks with small cpu value
[ https://issues.apache.org/jira/browse/MESOS-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975492#comment-14975492 ] haosdent commented on MESOS-2635: - Seems I could not found values depends on metrics in frameworks.html Could you provide more details about this? Last time I found only slave and master pages depends on values have to got from metrics endpoint, so I only update them. > Web UI Display Bug when starting lots of tasks with small cpu value > --- > > Key: MESOS-2635 > URL: https://issues.apache.org/jira/browse/MESOS-2635 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.22.0 >Reporter: Lukas Loesche >Assignee: haosdent >Priority: Minor > Fix For: 0.25.0 > > Attachments: Screen Shot 2015-04-17 at 18.53.54.png, fixed_after.png, > fixed_before.png > > > During Marathon scale testing we encountered a display bug where the Mesos > Web UI would show -4.064304448547773e-11 Idle CPUs in the Resources overview. > To reproduce, we started: > "cmd": "python -m SimpleHTTPServer $PORT0", > "cpus": 0.0001, > "instances": 2000, > "mem": 32, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3599) COMMAND health checks with marathon running in slave context broken
[ https://issues.apache.org/jira/browse/MESOS-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976671#comment-14976671 ] haosdent commented on MESOS-3599: - As you see, I expose it as $MESOS_CONTAINER_NAME in https://reviews.apache.org/r/39387/diff/1#2 > COMMAND health checks with marathon running in slave context broken > --- > > Key: MESOS-3599 > URL: https://issues.apache.org/jira/browse/MESOS-3599 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Erhan Kesken >Assignee: haosdent >Priority: Critical > > When deploying Mesos 0.23rc4 with latest Marathon 0.10.0 RC3 command health > check stop working. Rolling back to Mesos 0.22.1 fixes the problem. > Containerizer is Docker. > All packages are from official Mesosphere Ubuntu 14.04 sources. > The issue must be analyzed further. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3599) COMMAND health checks with marathon running in slave context broken
[ https://issues.apache.org/jira/browse/MESOS-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976675#comment-14976675 ] haosdent commented on MESOS-3599: - I think we could ping [~tnachen] again to review the patch. ;-) > COMMAND health checks with marathon running in slave context broken > --- > > Key: MESOS-3599 > URL: https://issues.apache.org/jira/browse/MESOS-3599 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Erhan Kesken >Assignee: haosdent >Priority: Critical > > When deploying Mesos 0.23rc4 with latest Marathon 0.10.0 RC3 command health > check stop working. Rolling back to Mesos 0.22.1 fixes the problem. > Containerizer is Docker. > All packages are from official Mesosphere Ubuntu 14.04 sources. > The issue must be analyzed further. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3216) virtual memory exhausted:: Cannot allocate memory
[
https://issues.apache.org/jira/browse/MESOS-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976728#comment-14976728
]
haosdent commented on MESOS-3216:
-
hmm, last time I try to build Mesos in a virtual machine which only have 1GB
also have similar problem. I have to change the memory to 2GB and make build
pass.
> virtual memory exhausted:: Cannot allocate memory
> -
>
> Key: MESOS-3216
> URL: https://issues.apache.org/jira/browse/MESOS-3216
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.23.0
> Environment: Linux Kudu 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24
> 21:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> (Ubuntu 15.04)
>Reporter: Samuel Marks
>
> After receiving this error when building on a virtual instance, I decided to
> build a package using https://github.com/deric/mesos-deb-packaging.
> Here is the last little bit of the output after running {{./build_mesos --ref
> 0.23.0 --build-version p1}}:
> {code}
> mv -f common/.deps/libmesos_no_3rdparty_la-http.Tpo
> common/.deps/libmesos_no_3rdparty_la-http.Plo
> /bin/bash ../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"mesos\"
> -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"0.23.0\"
> -DPACKAGE_STRING=\"mesos\ 0.23.0\" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" -DVERSION=\"0.23.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1
> -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1
> -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
> -DHAVE_LIBSASL2=1 -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\"
> -DMESOS_HAS_PYTHON=1 -I.
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src -Wall
> -Werror -DLIBDIR=\"/usr/lib\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\"
> -DPKGDATADIR=\"/usr/share/mesos\"
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/include
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/3rdparty/libprocess/include
>
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/3rdparty/libprocess/3rdparty/stout/include
> -I../include -I../include/mesos
> -I../3rdparty/libprocess/3rdparty/boost-1.53.0
> -I../3rdparty/libprocess/3rdparty/picojson-4f93734
> -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
> -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src
> -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src
> -I../3rdparty/leveldb/include -I../3rdparty/zookeeper-3.4.5/src/c/include
> -I../3rdparty/zookeeper-3.4.5/src/c/generated
> -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
> -I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
> -pthread -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -std=c++11
> -MT master/allocator/libmesos_no_3rdparty_la-allocator.lo -MD -MP -MF
> master/allocator/.deps/libmesos_no_3rdparty_la-allocator.Tpo -c -o
> master/allocator/libmesos_no_3rdparty_la-allocator.lo `test -f
> 'master/allocator/allocator.cpp' || echo
> '/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src/'`master/allocator/allocator.cpp
> libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
> -DPACKAGE_VERSION=\"0.23.0\" "-DPACKAGE_STRING=\"mesos 0.23.0\""
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
> -DVERSION=\"0.23.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1 -DHAVE_APR_POOLS_H=1
> -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1
> -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBSASL2=1
> -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I.
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src -Wall
> -Werror -DLIBDIR=\"/usr/lib\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\"
> -DPKGDATADIR=\"/usr/share/mesos\"
> -I/linked_rep
[jira] [Commented] (MESOS-3809) Expose advertise_ip and advertise_port as command line options in mesos slave
[ https://issues.apache.org/jira/browse/MESOS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14977853#comment-14977853 ] haosdent commented on MESOS-3809: - +1 please also update https://github.com/apache/mesos/blob/master/docs/configuration.md at the same time. > Expose advertise_ip and advertise_port as command line options in mesos slave > - > > Key: MESOS-3809 > URL: https://issues.apache.org/jira/browse/MESOS-3809 > Project: Mesos > Issue Type: Bug > Components: slave >Affects Versions: 0.25.0 >Reporter: Anindya Sinha >Assignee: Anindya Sinha >Priority: Minor > > advertise_ip and advertise_port are exposed as mesos master command line args > (MESOS-809). But the following use case makes it a candidate for adding as > command line args in mesos slave as well. > On Tue, Oct 27, 2015 at 7:43 PM, Xiaodong Zhang <xdzh...@alauda.io> wrote: > It works! Thanks a lot. > 发件人: haosdent <haosd...@gmail.com> > 答复: "u...@mesos.apache.org" <u...@mesos.apache.org> > 日期: 2015年10月28日 星期三 上午10:23 > 至: user <u...@mesos.apache.org> > 主题: Re: How to tell master which ip to connect. > Do you try `export LIBPROCESS_ADVERTISE_IP=xxx` and > `LIBPROCESS_ADVERTISE_PORT` when start slave? > On Wed, Oct 28, 2015 at 10:16 AM, Xiaodong Zhang <xdzh...@alauda.io> wrote: > Hi teams: > My scenarios is like this: > My master nodes were deployed in AWS. My slaves were in AZURE.So they > communicate via public ip. > I got trouble when slaves try to register to master. > Now slaves can get master’s public ip address,and can send register > request.But they can only send there private ip to master.(Because they don’t > know there public ip,thus they can’t not bind a public ip via —ip flag), > thus masters can’t connect slaves.How can the slave to tell master which ip > master should connect(I can’t find any flags like —advertise_ip in master). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3803) system requirenments on debian
shiyao.ma created MESOS-3803: Summary: system requirenments on debian Key: MESOS-3803 URL: https://issues.apache.org/jira/browse/MESOS-3803 Project: Mesos Issue Type: Documentation Reporter: shiyao.ma Priority: Trivial ITSM the package libz-dev is missing in the system requirements for ubuntu -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3224) Create a Mesos Contributor Newbie Guide
[
https://issues.apache.org/jira/browse/MESOS-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973318#comment-14973318
]
haosdent commented on MESOS-3224:
-
{noformat}
NewbieContributionOverview.jpg
{noformat}
Seems could not find this image.
{noformat}
* Required installations
+ GTest
+ GLog
{noformat}
Because we bundle gtest and glog in 3rdparty folder, do we still need install
them?
{noformat}
# Download and Build Mesos
{noformat}
It would be better add get start link at here.
http://mesos.apache.org/gettingstarted/
> Create a Mesos Contributor Newbie Guide
> ---
>
> Key: MESOS-3224
> URL: https://issues.apache.org/jira/browse/MESOS-3224
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Timothy Chen
>Assignee: Diana Arroyo
>
> Currently the website doesn't have a helpful guide for community users to
> know how to start learning to contribute to Mesos, understand the concepts
> and lower the barrier to get involved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3224) Create a Mesos Contributor Newbie Guide
[ https://issues.apache.org/jira/browse/MESOS-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14966771#comment-14966771 ] haosdent commented on MESOS-3224: - Move to github pull request or review board? > Create a Mesos Contributor Newbie Guide > --- > > Key: MESOS-3224 > URL: https://issues.apache.org/jira/browse/MESOS-3224 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Timothy Chen >Assignee: Diana Arroyo > > Currently the website doesn't have a helpful guide for community users to > know how to start learning to contribute to Mesos, understand the concepts > and lower the barrier to get involved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[ https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14968410#comment-14968410 ] haosdent commented on MESOS-3787: - For CommandInfo, I think Mesos already set them when start a docker container in mesos-docker-executor https://github.com/apache/mesos/blob/master/src/docker/docker.cpp#L421-L422. Do this not work for you? > As a developer, I'd like to be able to expand environment variables through > the Docker executor. > > > Key: MESOS-3787 > URL: https://issues.apache.org/jira/browse/MESOS-3787 > Project: Mesos > Issue Type: Wish >Reporter: John Garcia > Labels: mesosphere > > We'd like to have expanded variables usable in [the json files used to create > a Marathon app, hence] the Task's CommandInfo, so that the executor is able > to detect the correct values at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998837#comment-14998837
]
haosdent commented on MESOS-3870:
-
Ohoh, got it. Thank you for explanation.
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998700#comment-14998700
]
haosdent edited comment on MESOS-3870 at 11/10/15 3:09 PM:
---
Suppose a Process enqueue to runq twice(Or impossible, seems I could not find
any code avoid it enqueue multi times) when it receive two events.
And the Process dequeue in different work threads, and not yet running. In work
thread 1, Process pop event A and not yet running. In work thread 2, Process
pop event B and start running.
Is this scenario possible?
was (Author: haosd...@gmail.com):
Suppose a Process enqueue to runq twice(Or impossible, seems I could not find
any code avoid it enqueue multi times) when it receive two events.
And the dequeue in different work threads, and not yet running. In work thread
1, Process dequeue event A and not yet running. In work thread 2, Process
dequeue event B and start running.
Is this scenario possible?
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998884#comment-14998884
]
haosdent commented on MESOS-3870:
-
I think have another case make same Process run in different thread. Suppose
ProcessBase pop event A in thread 1 and change ProcessBase.state to BLOCKED in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L2463
. And not yet consume event B. Then event B reach and enqueue same Process to
ProcessManager.runq in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L3008
. Then ProcessManager dequeue it in thread 2 and pop event B and run event B
while thread 1 not yet running event A consume function. Is this possible?
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998700#comment-14998700
]
haosdent commented on MESOS-3870:
-
Suppose a Process enqueue to runq twice(Or impossible, seems I could not find
any code avoid it enqueue multi times) when it receive two events.
And the dequeue in different work threads, and not yet running. In work thread
1, Process dequeue event A and not yet running. In work thread 2, Process
dequeue event B and start running.
Is this scenario possible?
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998757#comment-14998757
]
haosdent commented on MESOS-3870:
-
Yes, but ProcessBase.state don't have violate. I am not sure if it will still
get dirty value while it change in other thread.
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998686#comment-14998686
]
haosdent commented on MESOS-3870:
-
I think ProcessManager could dequeue same Process in different work thread?
{noformat}
ProcessBase* ProcessManager::dequeue()
{
// TODO(benh): Remove a process from this thread's runq. If there
// are no processes to run, and this is not a dedicated thread, then
// steal one from another threads runq.
ProcessBase* process = NULL;
synchronized (runq_mutex) {
if (!runq.empty()) {
process = runq.front();
runq.pop_front();
// Increment the running count of processes in order to support
// the Clock::settle() operation (this must be done atomically
// with removing the process from the runq).
running.fetch_add(1);
}
}
return process;
}
{noformat}
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998730#comment-14998730
]
haosdent commented on MESOS-3870:
-
Yes, but I think it still could be enqueue twice? Because ProcessBase.state in
different CPU core caches.
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998884#comment-14998884
]
haosdent edited comment on MESOS-3870 at 11/10/15 4:49 PM:
---
I think have another case make same Process run in different thread. Suppose
ProcessBase pop event A in thread 1 and change ProcessBase.state to BLOCKED in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L2463
. And not yet consume event A. Then event B reach and enqueue same Process to
ProcessManager.runq in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L3008
. Then ProcessManager dequeue it in thread 2 and pop event B and run event B
while thread 1 not yet running event A consume function. Is this possible?
was (Author: haosd...@gmail.com):
I think have another case make same Process run in different thread. Suppose
ProcessBase pop event A in thread 1 and change ProcessBase.state to BLOCKED in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L2463
. And not yet consume event B. Then event B reach and enqueue same Process to
ProcessManager.runq in
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L3008
. Then ProcessManager dequeue it in thread 2 and pop event B and run event B
while thread 1 not yet running event A consume function. Is this possible?
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998971#comment-14998971
]
haosdent commented on MESOS-3870:
-
... Looks not possible. Only after consume event A, ProcessBase.state become
BLOCKED.
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3216) virtual memory exhausted:: Cannot allocate memory
[
https://issues.apache.org/jira/browse/MESOS-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3216:
---
Assignee: haosdent
> virtual memory exhausted:: Cannot allocate memory
> -
>
> Key: MESOS-3216
> URL: https://issues.apache.org/jira/browse/MESOS-3216
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.23.0
> Environment: Linux Kudu 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24
> 21:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> (Ubuntu 15.04)
>Reporter: Samuel Marks
>Assignee: haosdent
>
> After receiving this error when building on a virtual instance, I decided to
> build a package using https://github.com/deric/mesos-deb-packaging.
> Here is the last little bit of the output after running {{./build_mesos --ref
> 0.23.0 --build-version p1}}:
> {code}
> mv -f common/.deps/libmesos_no_3rdparty_la-http.Tpo
> common/.deps/libmesos_no_3rdparty_la-http.Plo
> /bin/bash ../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"mesos\"
> -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"0.23.0\"
> -DPACKAGE_STRING=\"mesos\ 0.23.0\" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" -DVERSION=\"0.23.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1
> -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1
> -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
> -DHAVE_LIBSASL2=1 -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\"
> -DMESOS_HAS_PYTHON=1 -I.
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src -Wall
> -Werror -DLIBDIR=\"/usr/lib\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\"
> -DPKGDATADIR=\"/usr/share/mesos\"
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/include
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/3rdparty/libprocess/include
>
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/3rdparty/libprocess/3rdparty/stout/include
> -I../include -I../include/mesos
> -I../3rdparty/libprocess/3rdparty/boost-1.53.0
> -I../3rdparty/libprocess/3rdparty/picojson-4f93734
> -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
> -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src
> -I../3rdparty/libprocess/3rdparty/glog-0.3.3/src
> -I../3rdparty/leveldb/include -I../3rdparty/zookeeper-3.4.5/src/c/include
> -I../3rdparty/zookeeper-3.4.5/src/c/generated
> -I../3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
> -I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
> -pthread -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -std=c++11
> -MT master/allocator/libmesos_no_3rdparty_la-allocator.lo -MD -MP -MF
> master/allocator/.deps/libmesos_no_3rdparty_la-allocator.Tpo -c -o
> master/allocator/libmesos_no_3rdparty_la-allocator.lo `test -f
> 'master/allocator/allocator.cpp' || echo
> '/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src/'`master/allocator/allocator.cpp
> libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
> -DPACKAGE_VERSION=\"0.23.0\" "-DPACKAGE_STRING=\"mesos 0.23.0\""
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
> -DVERSION=\"0.23.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1 -DHAVE_APR_POOLS_H=1
> -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1
> -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBSASL2=1
> -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I.
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/src -Wall
> -Werror -DLIBDIR=\"/usr/lib\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\"
> -DPKGDATADIR=\"/usr/share/mesos\"
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/include
> -I/linked_replaced_actual_path/mesos-deb-packaging/mesos-repo/3rdparty/li
[jira] [Commented] (MESOS-3827) Improve compilation speed of GMock tests
[ https://issues.apache.org/jira/browse/MESOS-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14995690#comment-14995690 ] haosdent commented on MESOS-3827: - Sounds great! > Improve compilation speed of GMock tests > > > Key: MESOS-3827 > URL: https://issues.apache.org/jira/browse/MESOS-3827 > Project: Mesos > Issue Type: Improvement >Reporter: Neil Conway >Assignee: Neil Conway >Priority: Minor > Labels: mesosphere, tech-debt, testing > > The GMock docs suggest that moving the definition of mock classes' > constructors and destructors to a separate compilation unit can improve > compile performance: > https://code.google.com/p/googlemock/wiki/V1_7_CookBook#Making_the_Compilation_Faster -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3906) post-reviews.py does not correctly upload binary files
[ https://issues.apache.org/jira/browse/MESOS-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003432#comment-15003432 ] haosdent commented on MESOS-3906: - Hi, this is not post-reviews.py problem. Please apply this https://reviews.reviewboard.org/r/7571/diff/1#index_header to your rbtools. > post-reviews.py does not correctly upload binary files > -- > > Key: MESOS-3906 > URL: https://issues.apache.org/jira/browse/MESOS-3906 > Project: Mesos > Issue Type: Bug > Components: reviewbot >Reporter: Benjamin Bannier > > I was changing images in `docs/images`, and uploading commits with > `support/post-reviews.py`. > After that the review request appeared with mangled diffs in ReviewBoard. > Sadly this was not apparent from the web ui since the images where not > displayed. > I am using RBTools 0.7.2 under OS X 10.10.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3915) Upgrade vendored Boost to 1.59
[ https://issues.apache.org/jira/browse/MESOS-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004260#comment-15004260 ] haosdent commented on MESOS-3915: - +1 > Upgrade vendored Boost to 1.59 > -- > > Key: MESOS-3915 > URL: https://issues.apache.org/jira/browse/MESOS-3915 > Project: Mesos > Issue Type: Bug >Reporter: Neil Conway >Priority: Minor > Labels: boost, mesosphere, tech-debt > > We should upgrade the vendored version of Boost to a newer version. Benefits: > * Should properly fix MESOS-688 > * Should fix MESOS-3799 > * Generally speaking, using a more modern version of Boost means we can take > advantage of bug fixes, optimizations, and new features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005726#comment-15005726
]
haosdent edited comment on MESOS-3928 at 11/15/15 4:55 AM:
---
Do you try disable iptables and change you centos-mesos-dev to a accessible ip
instead of 127.0.0.1 in /etc/hosts when running
DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged? Because when use
bridged mode, if slave listen on 127.0.0.1, docker container could not
communicate with it.
was (Author: haosd...@gmail.com):
Do you try disable iptables and change you localhost to a accessible ip instead
of 127.0.0.1 in /etc/hosts when running
DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged? Because when use
bridged mode, if slave listen on 127.0.0.1, docker container could not
communicate with it.
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Bernd Mathiske
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005726#comment-15005726
]
haosdent commented on MESOS-3928:
-
Do you try disable iptables and change you localhost to a accessible ip instead
of 127.0.0.1 in /etc/hosts when running
DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged? Because when use
bridged mode, if slave listen on 127.0.0.1, docker container could not
communicate with it.
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Bernd Mathiske
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2262) Adding GPGPU resource into Mesos, so we can know if any GPU/Heterogeneous resource are available from slave
[ https://issues.apache.org/jira/browse/MESOS-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005880#comment-15005880 ] haosdent commented on MESOS-2262: - I think you could use the docker image provided by Nvidia https://github.com/NVIDIA/nvidia-docker and Marathon constraints operator to make sure your jobs only run in those machine have GPGPU resource. For more exactly control for GPGPU resource. So far Mesos don't provide this. > Adding GPGPU resource into Mesos, so we can know if any GPU/Heterogeneous > resource are available from slave > --- > > Key: MESOS-2262 > URL: https://issues.apache.org/jira/browse/MESOS-2262 > Project: Mesos > Issue Type: Task > Components: slave > Environment: OpenCL support env, such as OS X, Linux, Windows.. >Reporter: chester kuo >Assignee: chester kuo >Priority: Minor > > Extending Mesos to support Heterogeneous resource such as GPGPU/FPGA..etc as > computing resources in the data-center, OpenCL will be first target to add > into Mesos (support by all major GPU vendor) , I will reserve to support > others such as CUDA in the future. > In this feature, slave will be supported to do resources discover including > but not limited to, > (1) Heterogeneous Computing programming model : "OpenCL". "CUDA", "HSA" > (2) Computing global memory (MB) > (3) Computing run time version , such as "1.2" , "2.0" > (4) Computing compute unit (double) > (5) Computing device type : GPGPU, CPU, Accelerator device. > (6) Computing (number of devices): (double) > The Heterogeneous resource isolation will be supported in the framework > instead of in the slave devices side, the major reason here is , the > ecosystem , such as OpenCL operate on top of private device driver own by > vendors, only runtime library (OpenCL) is user-space application, so its hard > for us to do like Linux cgroup to have CPU/memory resource isolation. As a > result we may use run time library to do device isolation and memory > allocation. > (PS, if anyone know how to do it for GPGPU driver, please drop me a note) > Meanwhile, some run-time library (such as OpenCL) support to run on top of > CPU, so we need to use isolator API to notify this once it allocated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3815) docker executor not works when SSL enable
[ https://issues.apache.org/jira/browse/MESOS-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3815: Comment: was deleted (was: Patch: https://reviews.apache.org/r/39944/ https://reviews.apache.org/r/39945/) > docker executor not works when SSL enable > - > > Key: MESOS-3815 > URL: https://issues.apache.org/jira/browse/MESOS-3815 > Project: Mesos > Issue Type: Bug >Reporter: haosdent >Assignee: haosdent > > Because docker executor not pass SSL related environment variables, > mesos-docker-executor could not works normal when SSL enable. More details > could found in http://search-hadoop.com/m/0Vlr6DsslDSvVs72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3815) docker executor not works when SSL enable
[ https://issues.apache.org/jira/browse/MESOS-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007758#comment-15007758 ] haosdent commented on MESOS-3815: - Let me delete my comment. > docker executor not works when SSL enable > - > > Key: MESOS-3815 > URL: https://issues.apache.org/jira/browse/MESOS-3815 > Project: Mesos > Issue Type: Bug >Reporter: haosdent >Assignee: haosdent > > Because docker executor not pass SSL related environment variables, > mesos-docker-executor could not works normal when SSL enable. More details > could found in http://search-hadoop.com/m/0Vlr6DsslDSvVs72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3901) Enable Mesos to be able know when it is hosted behind a proxy with a URL prefix
Harpreet created MESOS-3901: --- Summary: Enable Mesos to be able know when it is hosted behind a proxy with a URL prefix Key: MESOS-3901 URL: https://issues.apache.org/jira/browse/MESOS-3901 Project: Mesos Issue Type: Improvement Components: webui Reporter: Harpreet If Mesos is run behind a proxy with a URL prefix e.g. https://:/services/mesos (`/services/mesos` being the URL prefix), sandboxes in mesos don't load. This happens because when Mesos is accessed through a proxy at https://:/services/mesos, Mesos tries to request slave state from https://:/slave/20151110-232502-218431498-5050-1234-S1/slave(1)/state.json?jsonp=angular.callbacks._4. This URL is missing the /services/mesos path prefix, so the request fails. Fixing this by rewriting URLs in the body of every response, would not be a clean solution and can be error prone. After searching around a bit we've learned that this is apparently a common issue with webapps, because there is no standard specification for making them aware of their base URL path. Some will allow you to specify a base path in configuration[1], others will respect an X-Forwarded-Path header if a proxy provides it[2], and others don't handle this at all. It would be great to have explicit support in for this in Mesos. [1] http://search.cpan.org/~bobtfish/Catalyst-TraitFor-Request-ProxyBase-0.05/lib/Catalyst/TraitFor/Request/ProxyBase.pm [2] https://github.com/mattkenney/feedsquish/blob/master/rupta.py#L94 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3851) Investigate recent crashes in Command Executor
[
https://issues.apache.org/jira/browse/MESOS-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998453#comment-14998453
]
haosdent commented on MESOS-3851:
-
In the error log, registered and launchTaks have different thread id.
{noformat}
I1110 00:36:30.616987 5169 exec.cpp:306] Executor::launchTask took 160701ns
I1110 00:36:30.621285 5163 exec.cpp:222] Executor::registered took 399555ns
{noformat}
But in local test, these always have same thread id.
{noformat}
I1110 19:34:46.304114 8953 exec.cpp:222] Executor::registered took 182100ns
S1110 19:34:46.304416 8953 exec.cpp:306] Executor::launchTask took 47975ns
{noformat}
{noformat}
R1110 19:34:47.439801 9027 exec.cpp:222] Executor::registered took 257152ns
I1110 19:34:47.440234 9027 exec.cpp:306] Executor::launchTask took 111249ns
{noformat}
{noformat}
I1110 19:34:47.943961 9097 exec.cpp:222] Executor::registered took 271225ns
I1110 19:34:47.944284 9097 exec.cpp:306] Executor::launchTask took 45141ns
{noformat}
> Investigate recent crashes in Command Executor
> --
>
> Key: MESOS-3851
> URL: https://issues.apache.org/jira/browse/MESOS-3851
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Anand Mazumdar
>Priority: Blocker
> Labels: mesosphere
>
> Post https://reviews.apache.org/r/38900 i.e. updating CommandExecutor to
> support rootfs. There seem to be some tests showing frequent crashes due to
> assert violations.
> {{FetcherCacheTest.SimpleEviction}} failed due to the following log:
> {code}
> I1107 19:36:46.360908 30657 slave.cpp:1793] Sending queued task '3' to
> executor ''3' of framework 7d94c7fb-8950-4bcf-80c1-46112292dcd6- at
> executor(1)@172.17.5.200:33871'
> I1107 19:36:46.363682 1236 exec.cpp:297]
> I1107 19:36:46.373569 1245 exec.cpp:210] Executor registered on slave
> 7d94c7fb-8950-4bcf-80c1-46112292dcd6-S0
> @ 0x7f9f5a7db3fa google::LogMessage::Fail()
> I1107 19:36:46.394081 1245 exec.cpp:222] Executor::registered took 395411ns
> @ 0x7f9f5a7db359 google::LogMessage::SendToLog()
> @ 0x7f9f5a7dad6a google::LogMessage::Flush()
> @ 0x7f9f5a7dda9e google::LogMessageFatal::~LogMessageFatal()
> @ 0x48d00a _CheckFatal::~_CheckFatal()
> @ 0x49c99d
> mesos::internal::CommandExecutorProcess::launchTask()
> @ 0x4b3dd7
> _ZZN7process8dispatchIN5mesos8internal22CommandExecutorProcessEPNS1_14ExecutorDriverERKNS1_8TaskInfoES5_S6_EEvRKNS_3PIDIT_EEMSA_FvT0_T1_ET2_T3_ENKUlPNS_11ProcessBaseEE_clESL_
> @ 0x4c470c
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal22CommandExecutorProcessEPNS5_14ExecutorDriverERKNS5_8TaskInfoES9_SA_EEvRKNS0_3PIDIT_EEMSE_FvT0_T1_ET2_T3_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x7f9f5a761b1b std::function<>::operator()()
> @ 0x7f9f5a749935 process::ProcessBase::visit()
> @ 0x7f9f5a74d700 process::DispatchEvent::visit()
> @ 0x48e004 process::ProcessBase::serve()
> @ 0x7f9f5a745d21 process::ProcessManager::resume()
> @ 0x7f9f5a742f52
> _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
> @ 0x7f9f5a74cf2c
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
> @ 0x7f9f5a74cedc
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
> @ 0x7f9f5a74ce6e
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
> @ 0x7f9f5a74cdc5
> _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
> @ 0x7f9f5a74cd5e
> _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
> @ 0x7f9f5624f1e0 (unknown)
> @ 0x7f9f564a8df5 start_thread
> @ 0x7f9f559b71ad __clone
> I1107 19:36:46.551370 30656 containerizer.cpp:1257] Executor for container
> '6553a617-6b4a-418d-9759-5681f45ff854' has exited
> I1107 19:36:46.551429 30656 containerizer.cpp:1074] Destroying container
> '6553a617-6b4a-418d-9759-5681f45ff854'
> I1107 19:36:46.553869 30656 containerizer.cpp:1257] Executor for container
> 'd2c1f924-c92a-453e-82b1-c294d09c4873' has exited
> {code}
> The r
[jira] [Commented] (MESOS-2376) Allow libprocess ip and port to be configured
[ https://issues.apache.org/jira/browse/MESOS-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998645#comment-14998645 ] Dimitri commented on MESOS-2376: [~hfaran] What do you mean ? I am trying to set the mesos binding ip to something more secure than 0.0.0.0. I am running mesos inside a docker container, should I bind in the docker environment or on the host ? I have tried both, none did work. I haven't tried to set LIBPROCESS_PORT since i am just trying to change the interface. I am quite suprirse by the lake of documentation for this feature, which is to me something that cannot make mesos usuable to production. > Allow libprocess ip and port to be configured > - > > Key: MESOS-2376 > URL: https://issues.apache.org/jira/browse/MESOS-2376 > Project: Mesos > Issue Type: Improvement > Components: java api >Reporter: Dario Rexin >Priority: Minor > > Currently if we want to configure the ip libprocess uses for communication, > we have to set the env var LIBPROCESS_IP, or LIBPROCESS_PORT for the port. > For the Java API this means, that the variable has to be set before the JVM > is started, because setting env vars from within JAVA is not possible / > non-trivial. Therefore it would be great to be able to pass them in to the > constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3870) Prevent out-of-order libprocess message delivery
[
https://issues.apache.org/jira/browse/MESOS-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998605#comment-14998605
]
haosdent commented on MESOS-3870:
-
I think although send could be ordered when only have a connection, but execute
also could be out-of-order in receiver. ProcessManager would create 8~cpu
number work threads to handle input messages. Because ProcessManager dispatch
work by event, same Process would be called in different thread for different
event.
> Prevent out-of-order libprocess message delivery
>
>
> Key: MESOS-3870
> URL: https://issues.apache.org/jira/browse/MESOS-3870
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere
>
> I was under the impression that {{send()}} provided in-order, unreliable
> message delivery. So if P1 sends <M1,M2> to P2, P2 might see <>, , ,
> or <M1,M2> — but not <M2,M1>.
> I suspect much of the code makes a similar assumption. However, it appears
> that this behavior is not guaranteed. slave.cpp:2217 has the following
> comment:
> {noformat}
> // TODO(jieyu): Here we assume that CheckpointResourcesMessages are
> // ordered (i.e., slave receives them in the same order master sends
> // them). This should be true in most of the cases because TCP
> // enforces in order delivery per connection. However, the ordering
> // is technically not guaranteed because master creates multiple
> // connections to the slave in some cases (e.g., persistent socket
> // to slave breaks and master uses ephemeral socket). This could
> // potentially be solved by using a version number and rejecting
> // stale messages according to the version number.
> {noformat}
> We can improve this situation by _either_: (1) fixing libprocess to guarantee
> ordered message delivery, e.g., by adding a sequence number, or (2)
> clarifying that ordered message delivery is not guaranteed, and ideally
> providing a tool to force messages to be delivered out-of-order.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3815) os environment variables not passing to docker-executor environment variables correctly
haosdent created MESOS-3815: --- Summary: os environment variables not passing to docker-executor environment variables correctly Key: MESOS-3815 URL: https://issues.apache.org/jira/browse/MESOS-3815 Project: Mesos Issue Type: Bug Reporter: haosdent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3815) os environment variables not passing to docker-executor environment variables correctly
[ https://issues.apache.org/jira/browse/MESOS-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3815: --- Assignee: haosdent > os environment variables not passing to docker-executor environment variables > correctly > --- > > Key: MESOS-3815 > URL: https://issues.apache.org/jira/browse/MESOS-3815 > Project: Mesos > Issue Type: Bug >Reporter: haosdent >Assignee: haosdent > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3740) LIBPROCESS_IP not passed to Docker containers
[
https://issues.apache.org/jira/browse/MESOS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984315#comment-14984315
]
haosdent commented on MESOS-3740:
-
Hi, [~cmaloney] A little thing I could not understand here, in which case, we
need pass LIBPROCESS_IP to docker containers? Because only
mesos-docker-executor would communicate with agent and docker container is
managed by mesos-docker-executor. Seems the docker containers not need know
LIBPROCESS_IP here. Or you refer to launch a seperate docker container to run
the executor when we specify docker_mesos_image flag?
> LIBPROCESS_IP not passed to Docker containers
> -
>
> Key: MESOS-3740
> URL: https://issues.apache.org/jira/browse/MESOS-3740
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.25.0
> Environment: Mesos 0.24.1
>Reporter: Cody Maloney
>Assignee: Michael Park
> Labels: mesosphere
>
> Docker containers aren't currently passed all the same environment variables
> that Mesos Containerizer tasks are. See:
> https://github.com/apache/mesos/blob/master/src/slave/containerizer/containerizer.cpp#L254
> for all the environment variables explicitly set for mesos containers.
> While some of them don't necessarily make sense for docker containers, when
> the docker has inside of it a libprocess process (A mesos framework
> scheduler) and is using {{--net=host}} the task needs to have LIBPROCESS_IP
> set otherwise the same sort of problems that happen because of MESOS-3553 can
> happen (libprocess will try to guess the machine's IP address with likely bad
> results in a number of operating environment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3817) Rename offers to outstanding offers
haosdent created MESOS-3817: --- Summary: Rename offers to outstanding offers Key: MESOS-3817 URL: https://issues.apache.org/jira/browse/MESOS-3817 Project: Mesos Issue Type: Bug Components: webui Reporter: haosdent As discussion in http://search-hadoop.com/m/0Vlr6NFAux1DPmxp , we need rename offers to outstanding offers in webui to avoid user confuse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2960) Configure DiscoveryInfo and Visibility per port
[ https://issues.apache.org/jira/browse/MESOS-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14985342#comment-14985342 ] haosdent commented on MESOS-2960: - ping [~adam-mesos][~mcypark] Could you help review the patch? > 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 > > 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] [Commented] (MESOS-3822) Cannot specify multiple masters when slave start up
[
https://issues.apache.org/jira/browse/MESOS-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986760#comment-14986760
]
haosdent commented on MESOS-3822:
-
I think this is just because document not sync with code. Need change to
{noformat}
hostname or ip to a master e.g.,
--master=localhost:5050
{noformat}
> Cannot specify multiple masters when slave start up
>
>
> Key: MESOS-3822
> URL: https://issues.apache.org/jira/browse/MESOS-3822
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Guangya Liu
> Labels: docuentation
> Fix For: 0.26.0
>
>
> This bug is reported from user list, the document should be updated by
> removing multiple masters when slave start up.
> /usr/sbin/mesos-slave --master=IP1:5050,IP2:5050,IP3:5050 …. --credential …
> Only if IP1 is the leader, the slave can register to master successfully, Or
> it will register fail.
> Slave log like this:
> Creating new client SASL connection
> Authentication timed out
> Failed to authenticate with master master@172.31.43.77:5050: Authentication
> discarded
> Authenticating with master master@172.31.43.77:5050
> Using default CRAM-MD5 authenticatee
> Is this a bug?Or it is designed like this.
> BTW: --master:zk://xxx work well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3821) DOCKER_HOST does not work well with --executor_environment_variables
[
https://issues.apache.org/jira/browse/MESOS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986758#comment-14986758
]
haosdent commented on MESOS-3821:
-
hmm, let me submit a patch to this later.
> DOCKER_HOST does not work well with --executor_environment_variables
>
>
> Key: MESOS-3821
> URL: https://issues.apache.org/jira/browse/MESOS-3821
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.25.0
> Environment: Docker 1.7.1
> Mesos 0.25.0
>Reporter: Lei Xu
>
> Hi guys,
> I found that DOCKER_HOST does not work now if I set
> bq. --executor_environment_variables={"DOCKER_HOST":"localhost:2377"}
> but the docker executor always append
> bq. -H unix:///var/run/docker.sock
> on each command, it will overwrite the DOCKER_HOST in fact.
> I think it is too strict now, and I could not disable it via some command
> flags.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3821) DOCKER_HOST does not work well with --executor_environment_variables
[
https://issues.apache.org/jira/browse/MESOS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3821:
---
Assignee: haosdent
> DOCKER_HOST does not work well with --executor_environment_variables
>
>
> Key: MESOS-3821
> URL: https://issues.apache.org/jira/browse/MESOS-3821
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.25.0
> Environment: Docker 1.7.1
> Mesos 0.25.0
>Reporter: Lei Xu
>Assignee: haosdent
>
> Hi guys,
> I found that DOCKER_HOST does not work now if I set
> bq. --executor_environment_variables={"DOCKER_HOST":"localhost:2377"}
> but the docker executor always append
> bq. -H unix:///var/run/docker.sock
> on each command, it will overwrite the DOCKER_HOST in fact.
> I think it is too strict now, and I could not disable it via some command
> flags.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3822) Cannot specify multiple masters when slave start up
[ https://issues.apache.org/jira/browse/MESOS-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3822: Labels: docuentation (was: ) > Cannot specify multiple masters when slave start up > > > Key: MESOS-3822 > URL: https://issues.apache.org/jira/browse/MESOS-3822 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.26.0 >Reporter: Guangya Liu > Labels: docuentation > Fix For: 0.26.0 > > > This bug is reported from user list, the document should be updated by > removing multiple masters when slave start up. > /usr/sbin/mesos-slave --master=IP1:5050,IP2:5050,IP3:5050 …. --credential … > Only if IP1 is the leader, the slave can register to master successfully, Or > it will register fail. > Slave log like this: > Creating new client SASL connection > Authentication timed out > Failed to authenticate with master master@172.31.43.77:5050: Authentication > discarded > Authenticating with master master@172.31.43.77:5050 > Using default CRAM-MD5 authenticatee > Is this a bug?Or it is designed like this. > BTW: --master:zk://xxx work well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3829) Error on gracefully shutdown task
[ https://issues.apache.org/jira/browse/MESOS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14990959#comment-14990959 ] haosdent commented on MESOS-3829: - DOCKER_STOP_TIMEOUT is used for http://docs.docker.com/engine/reference/commandline/stop/. According docker document, you could receive SIGTERM before SIGKILL. > Error on gracefully shutdown task > - > > Key: MESOS-3829 > URL: https://issues.apache.org/jira/browse/MESOS-3829 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.25.0 > Environment: Marathon: 0.12.0-RC1 > Mesos: 0.25.0 > Docker 1.9.0 >Reporter: Rafael Capucho > > Hello, > I'm suffering from the same error reported here[1]. I have configured my > mesos-slave environment as [2] setting DOCKER_STOP_TIMEOUT and > EXECUTOR_SHUTDOWN_GRACE_PERIOD. > When I see the sandbox stdout, I can see in the first line the declaration: > --stop_timeout="30secs" > properly configured, but when I click in "Destroy App" in Marathon the stdout > keep showing weird things[3] like repeatedly "Killing docker task Shutting > down". > In my code I deal with SIGTERM and it isn't being reached. > Thank you. > [1] - > https://groups.google.com/forum/?hl=en#!topic/marathon-framework/Oy0dN0Lron0 > [2] - https://paste.ee/r/grRyS > [3] - https://paste.ee/r/SghOr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3829) Error on gracefully shutdown task
[ https://issues.apache.org/jira/browse/MESOS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14990960#comment-14990960 ] haosdent commented on MESOS-3829: - Maybe because of this https://github.com/docker/docker/pull/3240 ? I think it maybe a docker issue. > Error on gracefully shutdown task > - > > Key: MESOS-3829 > URL: https://issues.apache.org/jira/browse/MESOS-3829 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.25.0 > Environment: Marathon: 0.12.0-RC1 > Mesos: 0.25.0 > Docker 1.9.0 >Reporter: Rafael Capucho > > Hello, > I'm suffering from the same error reported here[1]. I have configured my > mesos-slave environment as [2] setting DOCKER_STOP_TIMEOUT and > EXECUTOR_SHUTDOWN_GRACE_PERIOD. > When I see the sandbox stdout, I can see in the first line the declaration: > --stop_timeout="30secs" > properly configured, but when I click in "Destroy App" in Marathon the stdout > keep showing weird things[3] like repeatedly "Killing docker task Shutting > down". > In my code I deal with SIGTERM and it isn't being reached. > Thank you. > [1] - > https://groups.google.com/forum/?hl=en#!topic/marathon-framework/Oy0dN0Lron0 > [2] - https://paste.ee/r/grRyS > [3] - https://paste.ee/r/SghOr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3829) Error on gracefully shutdown task
[ https://issues.apache.org/jira/browse/MESOS-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991926#comment-14991926 ] haosdent commented on MESOS-3829: - Looks correct. > Error on gracefully shutdown task > - > > Key: MESOS-3829 > URL: https://issues.apache.org/jira/browse/MESOS-3829 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.25.0 > Environment: Marathon: 0.12.0-RC1 > Mesos: 0.25.0 > Docker 1.9.0 >Reporter: Rafael Capucho > > Hello, > I'm suffering from the same error reported here[1]. I have configured my > mesos-slave environment as [2] setting DOCKER_STOP_TIMEOUT and > EXECUTOR_SHUTDOWN_GRACE_PERIOD. > When I see the sandbox stdout, I can see in the first line the declaration: > --stop_timeout="30secs" > properly configured, but when I click in "Destroy App" in Marathon the stdout > keep showing weird things[3] like repeatedly "Killing docker task Shutting > down". > In my code I deal with SIGTERM and it isn't being reached. > Thank you. > [1] - > https://groups.google.com/forum/?hl=en#!topic/marathon-framework/Oy0dN0Lron0 > [2] - https://paste.ee/r/grRyS > [3] - https://paste.ee/r/SghOr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3462) Containerization issues with mesos running on CoreOS
[
https://issues.apache.org/jira/browse/MESOS-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-3462:
Assignee: (was: haosdent)
> Containerization issues with mesos running on CoreOS
>
>
> Key: MESOS-3462
> URL: https://issues.apache.org/jira/browse/MESOS-3462
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 0.24.0
> Environment: CoreOS 801.0.0 64-bit
>Reporter: Francis Chuang
>
> These are the steps to I used to build mesos 0.24.0 on Ubuntu 15.04 64-bit:
> wget http://www.apache.org/dist/mesos/0.24.0/mesos-0.24.0.tar.gz
> wget http://mirror.ventraip.net.au/apache/apr/apr-1.5.2.tar.gz
> wget http://mirror.ventraip.net.au/apache/apr/apr-util-1.5.4.tar.gz
> wget http://mirror.ventraip.net.au/apache/subversion/subversion-1.9.0.tar.gz
> wget http://www.sqlite.org/sqlite-amalgamation-3071501.zip
> wget ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz
> mkdir /tmp/mesos-build
> cd /tmp/mesos-build
> - Build apr
> tar zxf apr-$APR_VERSION.tar.gz
> cd apr-$APR_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/apr
> make
> make install
> cd ..
> - Build apr-util
> tar zxf apr-util-$APR_UTIL_VERSION.tar.gz
> cd apr-util-$APR_UTIL_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/apr-util
> --with-apr=/tmp/mesos-build/apr
> make
> make install
> cd ..
> - Build libsasl2
> tar zxf cyrus-sasl-$SASL_VERSION.tar.gz
> cd cyrus-sasl-$SASL_VERSION
> ./configure CC=gcc-4.8 CPPFLAGS=-I/usr/include/openssl
> --prefix=/tmp/mesos-build/sasl2 --enable-cram
> make
> make install
> cd ..
> - Build subversion
> tar zxf subversion-$SVN_VERSION.tar.gz
> unzip sqlite-amalgamation-$SQLITE_AMALGATION_VERSION.zip
> mv sqlite-amalgamation-$SQLITE_AMALGATION_VERSION/
> subversion-$SVN_VERSION/sqlite-amalgamation/
> cd subversion-$SVN_VERSION
> ./configure CC=gcc-4.8 CXX=g++-4.8 --prefix=/tmp/mesos-build/svn
> --with-apr=/tmp/mesos-build/apr --with-apr-util=/tmp/mesos-build/apr-util
> --with-sasl=/tmp/mesos-build/sasl2
> make
> make install
> cd ..
> - Build curl
> tar zxf curl-$CURL_VERSION.tar.gz
> cd curl-$CURL_VERSION
> ./configure CC=gcc-4.8 --prefix=/tmp/mesos-build/curl
> make
> make install
> cd ..
> - Build mesos
> tar zxf mesos-$MESOS_VERSION.tar.gz
> cd mesos-$MESOS_VERSION
> mkdir build
> cd build
> ../configure CC=gcc-4.8 CXX=g++-4.8
> LD_LIBRARY_PATH=/tmp/mesos-build/sasl2/lib
> SASL_PATH=/tmp/mesos-build/sasl2/lib/sasl2 --prefix=/tmp/mesos-build/mesos
> --with-svn=/tmp/mesos-build/svn --with-apr=/tmp/mesos-build/apr
> --with-sasl=/tmp/mesos-build/sasl2/ --with-curl=/tmp/mesos-build/curl
> make
> make install
> cd ..
> cd ..
> - Copy shared objects into mesos build
> cp apr/lib/libapr-1.so.0.5.2 mesos/lib/libapr-1.so.0
> cp apr-util/lib/libaprutil-1.so.0.5.4 mesos/lib/libaprutil-1.so.0
> cp sasl2/lib/libsasl2.so.3.0.0 mesos/lib/libsasl2.so.3
> cp svn/lib/libsvn_delta-1.so.0.0.0 mesos/lib/libsvn_delta-1.so.0
> cp svn/lib/libsvn_subr-1.so.0.0.0 mesos/lib/libsvn_subr-1.so.0
> I then compress the build into an archive and distributed it onto my CoreOS
> nodes.
> Once I have the archive extracted on each node, I start the master and slaves:
> /opt/mesos/sbin/mesos-master --zk=zk://192.168.33.10/mesos --quorum=1
> --hostname=192.168.33.10 --ip=192.168.33.10
> --webui_dir=/opt/mesos/share/mesos/webui --cluster=mesos
> /opt/mesos/sbin/mesos-slave --hostname=192.168.33.11 --ip=192.168.33.11
> --master=zk://192.168.33.10/mesos
> --executor_environment_variables='{"LD_LIBRARY_PATH": "/opt/mesos/lib",
> "PATH": "/opt/java/bin:/usr/sbin:/usr/bin"}' --containerizers=docker,mesos
> --executor_registration_timeout=60mins
> --launcher_dir=/opt/mesos/libexec/mesos/
> In addition, the following environment variables are set:
> LD_LIBRARY_PATH=/opt/mesos/lib/
> JAVA_HOME=/opt/java
> MESOS_NATIVE_JAVA_LIBRARY=/opt/mesos/lib/libmesos.so
> I am finding that when I run meso-hdfs from
> https://github.com/mesosphere/hdfs, the scheduler starts properly and
> launches the executors. However, the executors will fail and terminate
> without writing any error to stderr and stdout.
> I have reproduced the same problem with mesos 0.24, 0.23 and 0.22.1
> If I install mesos onto a Ubuntu machine (tried 14.04 and 15.04 64-bit) using
> the apt-repositories, this problem does not happen.
> I am not well-versed with mesos internals, but it was pointed out that it's
> most likely a containerization issue. This issue on github documents the
> process of trying to get mesos-hdfs to work on my compiled mesos binaries:
> https://github.com/mesosphere/hdfs/issues/194
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-809) External control of the ip that Mesos components publish to zookeeper
[ https://issues.apache.org/jira/browse/MESOS-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994998#comment-14994998 ] Dimitri commented on MESOS-809: --- Sorry for interupting. I am trying hard to make mesos bind to a local interface instead of the public one. I have found this thread where it says that binding with env will do the trick. LIBPROCESS_ADVERTISE_IP: "10.0.0.3" CONSUL_IP: "10.0.0.3" I have tried both, but none work. I am using mesos with PanteraS, It's a bundled docker image for mesos. I have tried with the env on the host and in the panteras image, none work. could I have some help ? > External control of the ip that Mesos components publish to zookeeper > - > > Key: MESOS-809 > URL: https://issues.apache.org/jira/browse/MESOS-809 > Project: Mesos > Issue Type: Improvement > Components: framework, master, slave >Affects Versions: 0.14.2 >Reporter: Khalid Goudeaux >Assignee: Anindya Sinha >Priority: Minor > Fix For: 0.24.0 > > > With tools like Docker making containers more manageable, it's tempting to > use containers for all software installation. The CoreOS project is an > example of this. > When an application is run inside a container it sees a different ip/hostname > from the host system running the container. That ip is only valid from inside > that host, no other machine can see it. > From inside a container, the Mesos master and slave publish that private ip > to zookeeper and as a result they can't find each other if they're on > different machines. The --ip option can't help because the public ip isn't > available for binding from within a container. > Essentially, from inside the container, mesos processes don't know the ip > they're available at (they may not know the port either). > It would be nice to bootstrap the processes with the correct ip for them to > publish to zookeeper. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2587) libprocess should allow configuration of ip/port separate from the ones it binds to
[
https://issues.apache.org/jira/browse/MESOS-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994999#comment-14994999
]
Dimitri commented on MESOS-2587:
Sorry for interupting. I am trying hard to make mesos bind to a local interface
instead of the public one.
I have found this thread where it says that binding with env will do the trick.
LIBPROCESS_ADVERTISE_IP: "10.0.0.3"
CONSUL_IP: "10.0.0.3"
I have tried both, but none work.
I am using mesos with PanteraS, It's a bundled docker image for mesos. I have
tried with the env on the host and in the panteras image, none work. could I
have some help ?
> libprocess should allow configuration of ip/port separate from the ones it
> binds to
> ---
>
> Key: MESOS-2587
> URL: https://issues.apache.org/jira/browse/MESOS-2587
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Cosmin Lehene
>
> Currently libprocess will advertise {{LIBPROCESS_IP}}{{LIBPROCESS_PORT}}, but
> if a framework runs in a container without an an interface that has a
> publicly accessible IP (e.g. a container in bridge mode) it will advertise an
> IP that will not be reachable by master.
> With this, we could advertise the external IP (reachable from master) of the
> bridge from within a container.
> This should allow frameworks running in containers to work in the safer
> bridged mode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3815) docker executor not works when SSL enable
[ https://issues.apache.org/jira/browse/MESOS-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14995123#comment-14995123 ] haosdent commented on MESOS-3815: - Use exactly environment variables. https://reviews.apache.org/r/40046/diff/1 > docker executor not works when SSL enable > - > > Key: MESOS-3815 > URL: https://issues.apache.org/jira/browse/MESOS-3815 > Project: Mesos > Issue Type: Bug >Reporter: haosdent >Assignee: haosdent > > Because docker executor not pass SSL related environment variables, > mesos-docker-executor could not works normal when SSL enable. More details > could found in http://search-hadoop.com/m/0Vlr6DsslDSvVs72 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[ https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988693#comment-14988693 ] haosdent commented on MESOS-3787: - Because have two process? > As a developer, I'd like to be able to expand environment variables through > the Docker executor. > > > Key: MESOS-3787 > URL: https://issues.apache.org/jira/browse/MESOS-3787 > Project: Mesos > Issue Type: Wish >Reporter: John Garcia > Labels: mesosphere > Attachments: mesos.patch, test-example.json > > > We'd like to have expanded variables usable in [the json files used to create > a Marathon app, hence] the Task's CommandInfo, so that the executor is able > to detect the correct values at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3787) As a developer, I'd like to be able to expand environment variables through the Docker executor.
[ https://issues.apache.org/jira/browse/MESOS-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988726#comment-14988726 ] haosdent commented on MESOS-3787: - I notice the second item in you post about "ps" have already show the variables. > As a developer, I'd like to be able to expand environment variables through > the Docker executor. > > > Key: MESOS-3787 > URL: https://issues.apache.org/jira/browse/MESOS-3787 > Project: Mesos > Issue Type: Wish >Reporter: John Garcia > Labels: mesosphere > Attachments: mesos.patch, test-example.json > > > We'd like to have expanded variables usable in [the json files used to create > a Marathon app, hence] the Task's CommandInfo, so that the executor is able > to detect the correct values at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
