[jira] [Commented] (MESOS-9748) Consider installing filters if offers time out
[ https://issues.apache.org/jira/browse/MESOS-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16829024#comment-16829024 ] Benjamin Bannier commented on MESOS-9748: - [~chhsia0], one could also argue that a framework which let's offers time out instead of accepting or declining them has already violated the offer protocol. I agree that implicit behavior can be confusing, but I believe one could argue here from a position of Mesos guarding itself against misbehaving frameworks (especially important since we rely on frameworks behaving correctly). > Consider installing filters if offers time out > -- > > Key: MESOS-9748 > URL: https://issues.apache.org/jira/browse/MESOS-9748 > Project: Mesos > Issue Type: Improvement > Components: allocation, master >Reporter: Benjamin Bannier >Priority: Major > > We currently do not install any filters if an offer to a framework times out. > We should consider recovering with a filter for some duration. > This can be interesting in cases where e.g., framework offer processing is > backlogged so it cannot accept offers in time. If no filter is installed we > could end up allocating to that framework again and again (and exclusively if > other frameworks already use more resources than what we offer the backlogged > framework at a time). > If we would instead filter the resources from timed out offers for some > allocation cycle, we could extert some form of backpressure on the > framework's behalf which could allow it to recover. We also would give a > chance that other frameworks can actually use the resources. > The optimal duration to filter the resources for would depend on the > (dynamic) number of frameworks interested in offers and might be hard to > determine. Filtering for a single allocation cycle might be a good starting > point to get some of the benefits without causing too much new behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9536) Nested container launched with non-root user may not be able to write to its sandbox via the environment variable `MESOS_SANDBOX`
[
https://issues.apache.org/jira/browse/MESOS-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16829023#comment-16829023
]
Qian Zhang commented on MESOS-9536:
---
commit 40beae143a24a35f85b047ef8ee243581f1c3c69
Author: Qian Zhang
Date: Fri Apr 19 17:22:45 2019 +0800
Made nested contaienr can access its sandbox via `MESOS_SANDBOX`.
Previously in MESOS-8332 we narrowed task sandbox permissions from 0755
to 0750 which will cause nested container may not has permission to
access its sandbox via the environment variable `MESOS_SANDBOX`. Now in
this patch, for nested container which does not have its own rootfs, we
bind mount its sandbox to the directory specified via the agent flag
`--sandbox_directory` and set `MESOS_SANDBOX` to `--sandbox_directory`
as well, in this way such nested container will have the permission
to access its sandbox via `MESOS_SANDBOX`.
Review: [https://reviews.apache.org/r/70514]
commit 510aa02f9a53b1209e9deeaf65f25db2c0ccd96b
Author: Qian Zhang
Date: Mon Apr 22 15:44:35 2019 +0800
Added a test to verify non-root nested container can access its sandbox.
Review: https://reviews.apache.org/r/70515
> Nested container launched with non-root user may not be able to write to its
> sandbox via the environment variable `MESOS_SANDBOX`
> -
>
> Key: MESOS-9536
> URL: https://issues.apache.org/jira/browse/MESOS-9536
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.6.0, 1.6.1, 1.7.0, 1.8.0
>Reporter: Qian Zhang
>Assignee: Qian Zhang
>Priority: Critical
>
> Launch a nested container to write to its sandbox via the env var
> `MESOS_SANDBOX`. The nested container is launched with a non-root user (e.g.,
> `nobody`) and its parent container (i.e., the default executor) is launched
> with root since `mesos-execute` is executed with `sudo` in the example below.
> {code:java}
> $ sudo src/mesos-execute --master=:5050
> --task_group=file:///tmp/task_group.json
> $ cat /tmp/task_group.json
> {
> "tasks":[
> {
> "name" : "test",
> "task_id" : {"value" : "test"},
> "agent_id": {"value" : ""},
> "resources": [
> {"name": "cpus", "type": "SCALAR", "scalar": {"value": 0.1}},
> {"name": "mem", "type": "SCALAR", "scalar": {"value": 32}}
> ],
> "command": {
> "user": "nobody",
> "value": "echo data > $MESOS_SANDBOX/file"
> }
> }
> ]
> }
> {code}
> The nested container will fail.
> {code:java}
> I0125 16:04:03.610659 10064 scheduler.cpp:189] Version: 1.8.0
> I0125 16:04:03.641856 10066 scheduler.cpp:355] Using default 'basic' HTTP
> authenticatee
> I0125 16:04:03.643841 10063 scheduler.cpp:538] New master detected at
> master@192.168.56.5:5050
> Subscribed with ID 1ae64562-dbf9-4b24-af88-1cbcdc2ae71d-0002
> Submitted task group with tasks [ test ] to agent
> '12866186-dc2b-48a9-88ad-f9d951cf8c7f-S0'
> Received status update TASK_STARTING for task 'test'
> source: SOURCE_EXECUTOR
> Received status update TASK_RUNNING for task 'test'
> source: SOURCE_EXECUTOR
> Received status update TASK_FAILED for task 'test'
> message: 'Command exited with status 2'
> source: SOURCE_EXECUTOR
> {code}
> In the stderr of the nested container, we can see it has no permission to do
> the write.
> {code:java}
> $ sudo cat
> /opt/mesos/slaves/12866186-dc2b-48a9-88ad-f9d951cf8c7f-S0/frameworks/1ae64562-dbf9-4b24-af88-1cbcdc2ae71d-0002/executors/default-executor/runs/c7173fd8-9c01-49f5-a092-bdad78609260/containers/bf8f6ac8-2f8a-4300-9fe6-a830f602f654/stderr
>
> Marked '/' as rslave
> sh: 1: cannot create
> /opt/mesos/slaves/12866186-dc2b-48a9-88ad-f9d951cf8c7f-S0/frameworks/1ae64562-dbf9-4b24-af88-1cbcdc2ae71d-0002/executors/default-executor/runs/c7173fd8-9c01-49f5-a092-bdad78609260/containers/bf8f6ac8-2f8a-4300-9fe6-a830f602f654/file:
> Permission denied
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1797) Packaged Zookeeper does not compile on OSX Yosemite
[ https://issues.apache.org/jira/browse/MESOS-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1797: - Comment: was deleted (was: www.rtat.net) > Packaged Zookeeper does not compile on OSX Yosemite > --- > > Key: MESOS-1797 > URL: https://issues.apache.org/jira/browse/MESOS-1797 > Project: Mesos > Issue Type: Improvement > Components: build >Affects Versions: 0.19.1, 0.20.0, 0.21.0 >Reporter: Dario Rexin >Assignee: Benjamin Mahler >Priority: Minor > Fix For: 0.21.0 > > > I have been struggling with this for some time (due to my lack of knowledge > about C compiler error messages) and finally found a way to make it compile. > The problem is that Zookeeper defines a function `htonll` that is a builtin > function in Yosemite. For me it worked to just remove this function, but as > it needs to keep working on other systems as well, we would need some check > for the OS version or if the function is already defined. > Here are the links to the source: > https://github.com/apache/zookeeper/blob/trunk/src/c/include/recordio.h#L73 > https://github.com/apache/zookeeper/blob/trunk/src/c/src/recordio.c#L83-L97 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9592) Mesos Websitebot is flaky
[
https://issues.apache.org/jira/browse/MESOS-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9592:
-
Comment: was deleted
(was: www.rtat.net)
> Mesos Websitebot is flaky
> -
>
> Key: MESOS-9592
> URL: https://issues.apache.org/jira/browse/MESOS-9592
> Project: Mesos
> Issue Type: Bug
> Components: project website
>Reporter: Vinod Kone
>Assignee: Benjamin Bannier
>Priority: Major
> Labels: ci, integration
> Fix For: 1.8.0
>
>
> Mesos Websitebot Jenkins job is sometimes failing during the endpoint
> documentation generation face. It looks like it is timing out on getting a
> response from the /health endpoint of the master.
> Example failing build:
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Websitebot/1899/
> {code}
> 01:20:30 make[2]: Leaving directory '/mesos/build/src'
> 01:20:30 make[1]: Leaving directory '/mesos/build/src'
> 01:20:30 /mesos
> 01:20:41 Timeout attempting to hit url: http://127.0.0.1:5050/health
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7501) Change legacy --with-network-isolator to --with-port-mapping-isolator
[ https://issues.apache.org/jira/browse/MESOS-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7501: - Comment: was deleted (was: www.rtat.net) > Change legacy --with-network-isolator to --with-port-mapping-isolator > - > > Key: MESOS-7501 > URL: https://issues.apache.org/jira/browse/MESOS-7501 > Project: Mesos > Issue Type: Documentation > Components: cmake >Affects Versions: 1.2.0 > Environment: Build >Reporter: tim hansen >Assignee: Tim Hansen >Priority: Trivial > Labels: documentation > Fix For: 1.4.0 > > > Small documentation fix to change --with-network-isolator legacy name to a > more descriptive --with-port-mapping-isolator. This confusion caused a lot > of time spent pulling in dependencies for an unnecessary feature for our > build. Just cleaning it up to avoid further confusion in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4216) post-reviews.py should support multiple git worktrees
[
https://issues.apache.org/jira/browse/MESOS-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-4216:
-
Comment: was deleted
(was: www.rtat.net)
> post-reviews.py should support multiple git worktrees
> -
>
> Key: MESOS-4216
> URL: https://issues.apache.org/jira/browse/MESOS-4216
> Project: Mesos
> Issue Type: Improvement
> Components: build
>Reporter: Shuai Lin
>Priority: Trivial
>
> Git 2.5 add a new feature "multiple worktrees", e.g. one can checkout
> multiple worktrees of the same local git repo, which share the same .git
> directory.
> For example, the following command:
> {code}
> git worktree add -b new-branch ../mesos-new-branch master
> {code}
> would create a new folder {{mesos-new-branch}} in the parent folder of mesos
> source tree.
> See [this github
> blog|https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows]
> for details.
> This feature is quite handy when developing mesos: you can avoid re-compiling
> mesos (really costs a lot of time) when you need to temporary switch to
> another branch and switch back soon after: you just create a worktree, and do
> stuff there.
> Currently the {{post-reviews.py}} script doesn't work well if not running in
> the default worktree, becase it would look for the {{.git}} folder. In
> non-default worktree, `.git` is a file whose content points to the real
> `.git` dir.
> {code}
> $ cd ~/dev/mesos-new-branch
> $ cat .git
> gitdir: ~/dev/mesos/.git/worktrees/mesos-new-branch
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-967) configure: error: cannot find libsasl2
[ https://issues.apache.org/jira/browse/MESOS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-967: Comment: was deleted (was: www.rtat.net) > configure: error: cannot find libsasl2 > -- > > Key: MESOS-967 > URL: https://issues.apache.org/jira/browse/MESOS-967 > Project: Mesos > Issue Type: Bug > Components: build > Environment: Fedora 20 >Reporter: Vinson Lee >Assignee: Vinson Lee >Priority: Major > Fix For: 0.18.0 > > > export CC=clang > export CXX=clang++ > ./bootstrap > [...] > ./configure > [...] > checking whether clang++ supports C++11 features by default... no > checking whether clang++ supports C++11 features with -std=c++11... yes > checking for sasl_done in -lsasl2... no > configure: error: cannot find libsasl2 > --- > We need libsasl2 for authentication! > --- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5902) CMake should generate protobuf definitions for Java
[ https://issues.apache.org/jira/browse/MESOS-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5902: - Comment: was deleted (was: www.rtat.net) > CMake should generate protobuf definitions for Java > --- > > Key: MESOS-5902 > URL: https://issues.apache.org/jira/browse/MESOS-5902 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: CMake >Reporter: Srinivas >Assignee: Andrew Schwartzmeyer >Priority: Major > Labels: microsoft > Fix For: 1.5.0 > > > Currently Java protobuf bindings require java protobuf library to generate > and compile the sources. We should build protobuf-java-2.6.1.jar from the > protobuf sources just like we build the mesos protobuf for C++. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3248) Allow developers the option to pass parameters to modules programatically
[
https://issues.apache.org/jira/browse/MESOS-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-3248:
-
Comment: was deleted
(was: www.rtat.net)
> Allow developers the option to pass parameters to modules programatically
> -
>
> Key: MESOS-3248
> URL: https://issues.apache.org/jira/browse/MESOS-3248
> Project: Mesos
> Issue Type: Bug
> Components: modules
>Reporter: Alexander Rojas
>Priority: Major
> Labels: mesosphere
>
> h1.Introduction
> As it stands right now, default implementations of modularized components are
> required to have a non parametrized {{create()}} static method. This allows
> to write tests which can cover default implementations and modules based on
> these default implementations on a uniform way.
> For example, with the interface {{Foo}}:
> {code}
> class Foo {
> public:
> virtual ~Foo() {}
> virtual Future hello() = 0;
> protected:
> Foo() {}
> };
> {code}
> With a default implementation:
> {code}
> class LocalFoo {
> public:
> Try create() {
> return new Foo;
> }
> virtual Future hello() {
> return 1;
> }
> };
> {code}
> This allows to create typed tests which look as following:
> {code}
> typedef ::testing::Types tests::Module>
> FooTestTypes;
> TYPED_TEST_CASE(FooTest, FooTestTypes);
> TYPED_TEST(FooTest, ATest)
> {
> Try foo = TypeParam::create();
> ASSERT_SOME(foo);
> AWAIT_CHECK_EQUAL(foo.get()->hello(), 1);
> }
> {code}
> The test will be applied to each of types in the template parameters of
> {{FooTestTypes}}. This allows to test different implementation of an
> interface. In our code, it tests default implementations and a module which
> uses the same default implementation.
> The class {{tests::Module}} needs a little
> explanation, it is a wrapper around {{ModuleManager}} which allows the tests
> to encode information about the requested module in the type itself instead
> of passing a string to the factory method. The wrapper around create, the
> real important method looks as follows:
> {code}
> template
> static Try test::Module::create()
> {
> Try moduleName = getModuleName(N);
> if (moduleName.isError()) {
> return Error(moduleName.error());
> }
> return mesos::modules::ModuleManager::create(moduleName.get());
> }
> {code}
> h1.The Problem
> Consider the following implementation of {{Foo}}:
> {code}
> class ParameterFoo {
> public:
> Try create(int i) {
> return new ParameterFoo(i);
> }
> ParameterFoo(int i) : i_(i) {}
> virtual Future hello() {
> return i;
> }
> private:
> int i_;
> };
> {code}
> As it can be seen, this implementation cannot be used as a default
> implementation since its create API does not match the one of
> {{test::Module<>}}: {{create()}} has a different signature for both types. It
> is still a common situation to require initialization parameters for objects,
> however this constraint (keeping both interfaces alike) forces default
> implementations of modularized components to have default constructors,
> therefore the tests are forcing the design of the interfaces.
> Implementations which are supposed to be used as modules only, i.e. non
> default implementations are allowed to have constructor parameters, since the
> actual signature of their factory method is, this factory method's function
> is to decode the parameters and call the appropriate constructor:
> {code}
> template
> T* Module::create(const Parameters& params);
> {code}
> where parameters is just an array of key-value string pairs whose
> interpretation is left to the specific module. Sadly, this call is wrapped by
> {{ModuleManager}} which only allows module parameters to be passed from the
> command line and does not offer a programmatic way to feed construction
> parameters to modules.
> h1.The Ugly Workaround
> With the requirement of a default constructor and parameters devoid
> {{create()}} factory function, a common pattern (see
> [Authenticator|https://github.com/apache/mesos/blob/9d4ac11ed757aa5869da440dfe5343a61b07199a/include/mesos/authentication/authenticator.hpp])
> has been introduced to feed construction parameters into default
> implementation, this leads to adding an {{initialize()}} call to the public
> interface, which will have {{Foo}} become:
> {code}
> class Foo {
> public:
> virtual ~Foo() {}
> virtual Try initialize(Option i) = 0;
> virtual Future hello() = 0;
> protected:
> Foo() {}
> };
> {code}
> {{ParameterFoo}} will thus look as follows:
> {code}
> class ParameterFoo {
> public:
> Try create() {
> return new ParameterFoo;
> }
> ParameterFoo() : i_(None()) {}
> virtual Try initialize(Option i) {
> if (i.isNone()) {
> return Error("Need value to initialize");
[jira] [Issue Comment Deleted] (MESOS-9096) Consider introducing a linter to check changes to tag numbers in public protos
[ https://issues.apache.org/jira/browse/MESOS-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9096: - Comment: was deleted (was: www.rtat.net) > Consider introducing a linter to check changes to tag numbers in public protos > -- > > Key: MESOS-9096 > URL: https://issues.apache.org/jira/browse/MESOS-9096 > Project: Mesos > Issue Type: Improvement > Components: build >Reporter: Benjamin Bannier >Priority: Major > Labels: lint > > Right now detecting breaking changes to proto messages where a tag number > changes require manual inspection. It seems it should be possible to write a > proto linter which would detect such changes. > It could implement the following flow: > * check if the proto is public, e.g., in some public include path > * check that the diff contains no changes to tag numbers (same field name, > similar location). > We should also check whether such tools already exist and we could add them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-2049) 3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:2090:21: error: destination for this 'memset' call is a pointer to class containing a dynamic class 'Ex
[
https://issues.apache.org/jira/browse/MESOS-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-2049:
-
Comment: was deleted
(was: www.rtat.net)
> 3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:2090:21: error:
> destination for this 'memset' call is a pointer to class containing a dynamic
> class 'ExecutorInfo'; vtable pointer will be overwritten
> [-Werror,-Wdynamic-class-memaccess]
> ---
>
> Key: MESOS-2049
> URL: https://issues.apache.org/jira/browse/MESOS-2049
> Project: Mesos
> Issue Type: Bug
> Components: build
> Environment: Ubuntu 14.10
> clang 3.5
>Reporter: Vinson Lee
>Assignee: Michael Park
>Priority: Blocker
>
> libtool: compile: clang++ -DPACKAGE_NAME=\"mesos\"
> -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"0.22.0\"
> "-DPACKAGE_STRING=\"mesos 0.22.0\"" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" -DVERSION=\"0.22.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=1
> -DHAVE_LIBZ=1 -DHAVE_LIBCURL=1 -DHAVE_LIBAPR_1=1 -DHAVE_LIBSVN_SUBR_1=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBSASL2=1 -DMESOS_HAS_JAVA=1
> -DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I. -I../../src -Wall -Werror
> -DLIBDIR=\"/usr/local/lib\" -DPKGLIBEXECDIR=\"/usr/local/libexec/mesos\"
> -DPKGDATADIR=\"/usr/local/share/mesos\" -I../../include
> -I../../3rdparty/libprocess/include
> -I../../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 -g1 -O0 -std=c++11 -MT local/libmesos_no_3rdparty_la-local.lo -MD
> -MP -MF local/.deps/libmesos_no_3rdparty_la-local.Tpo -c
> ../../src/local/local.cpp -fPIC -DPIC -o
> local/.libs/libmesos_no_3rdparty_la-local.o
> In file included from ../../src/local/local.cpp:47:
> In file included from ../../src/master/hierarchical_allocator_process.hpp:39:
> In file included from ../../src/master/master.hpp:28:
> In file included from
> ../3rdparty/libprocess/3rdparty/boost-1.53.0/boost/circular_buffer.hpp:65:
> ../3rdparty/libprocess/3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:2090:21:
> error: destination for this 'memset' call is a pointer to class containing a
> dynamic class 'ExecutorInfo'; vtable pointer will be overwritten
> [-Werror,-Wdynamic-class-memaccess]
> std::memset(p, cb_details::UNINITIALIZED, sizeof(value_type) * n);
> ~~~ ^
> ../3rdparty/libprocess/3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:2177:18:
> note: in instantiation of member function
> 'boost::circular_buffer
> std::allocator
> >::allocate' requested here
> m_buff = allocate(buffer_capacity);
> ^
> ../3rdparty/libprocess/3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:1018:9:
> note: in instantiation of member function
> 'boost::circular_buffer
> std::allocator
> >::initialize_buffer' requested here
> initialize_buffer(buffer_capacity);
> ^
> ../../src/slave/monitor.hpp:99:7: note: in instantiation of member function
> 'boost::circular_buffer
> std::allocator
> >::circular_buffer' requested here
> archive(MONITORING_ARCHIVED_TIME_SERIES) {}
> ^
> ../3rdparty/libprocess/3rdparty/boost-1.53.0/boost/circular_buffer/base.hpp:2090:21:
> note: explicitly cast the pointer to silence this warning
> std::memset(p, cb_details::UNINITIALIZED, sizeof(value_type) * n);
> ^
> (void*)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9229) Install Python3 on ubuntu-16.04-arm docker image
[ https://issues.apache.org/jira/browse/MESOS-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9229: - Comment: was deleted (was: www.rtat.net) > Install Python3 on ubuntu-16.04-arm docker image > > > Key: MESOS-9229 > URL: https://issues.apache.org/jira/browse/MESOS-9229 > Project: Mesos > Issue Type: Task > Components: build, test >Reporter: Robin Gögge >Assignee: Tomasz Janiszewski >Priority: Minor > Fix For: 1.8.0 > > > With the upgrade to Python 3 in the Mesos codebase builds which rely on > docker images started to fail since they were missing a `python3` > installation. > We fixed those issues for most of the Docker images in > https://issues.apache.org/jira/browse/MESOS-8957. We still miss Python 3 on > the Ubuntu-16.04-arm image which can be found in > `support/mesos-build/ubuntu-16.04-arm`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8477) Make clean fails without Python artifacts.
[
https://issues.apache.org/jira/browse/MESOS-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8477:
-
Comment: was deleted
(was: www.rtat.net)
> Make clean fails without Python artifacts.
> --
>
> Key: MESOS-8477
> URL: https://issues.apache.org/jira/browse/MESOS-8477
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.5.0
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
>Priority: Major
> Fix For: 1.6.0
>
>
> Make clean may fail if there are no Python artifacts created by previous
> builds.
> {noformat}
> $ make clean{noformat}
> {noformat}
> [...]
> rm -rf java/target
> rm -f examples/java/*.class
> rm -f java/jni/org_apache_mesos*.h
> find python \( -name "build" -o -name "dist" -o -name "*.pyc" \
> -o -name "*.egg-info" \) -exec rm -rf '{}' \+
> find: ‘python’: No such file or directory
> make[1]: *** [clean-python] Error 1
> make[1]: Leaving directory `/home/centos/workspace/mesos/build/src'
> make: *** [clean-recursive] Error 1{noformat}
>
> Triggered by
> [https://github.com/apache/mesos/blob/62d392704c499e06da0323e50dfd016cdac06f33/src/Makefile.am#L2218-L2219]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5089) Remove PID in containerizer interfaces
[ https://issues.apache.org/jira/browse/MESOS-5089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5089: - Comment: was deleted (was: www.rtat.net) > Remove PID in containerizer interfaces > - > > Key: MESOS-5089 > URL: https://issues.apache.org/jira/browse/MESOS-5089 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent >Priority: Major > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7378) Build failure with glibc 2.12.
[
https://issues.apache.org/jira/browse/MESOS-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7378:
-
Comment: was deleted
(was: www.rtat.net)
> Build failure with glibc 2.12.
> --
>
> Key: MESOS-7378
> URL: https://issues.apache.org/jira/browse/MESOS-7378
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.3.0
>Reporter: James Peach
>Assignee: Neil Conway
>Priority: Blocker
> Fix For: 1.2.3, 1.3.0, 1.4.0
>
>
> {noformat}
> 03:46:16 - ./.libs/libmesos.so: undefined reference to
> `gnu_dev_minor(unsigned long long)'
> 03:46:16 - ./.libs/libmesos.so: undefined reference to
> `gnu_dev_major(unsigned long long)'
> {noformat}
> This is caused by the change in MESOS-7365.
> Including {{}} directly works on modern systems, but on our
> older version of glibc, the {{}} header does not contain C++
> decls. This means that the inline symbols get C++ name mangling applied and
> they don't get found at link time.
> {noformat}
> vagrant@mesos ~]$ cat /etc/redhat-release
> CentOS release 6.8 (Final)
> [vagrant@mesos ~]$ rpm -qa | grep glibc
> glibc-common-2.12-1.192.el6.x86_64
> glibc-devel-2.12-1.192.el6.x86_64
> glibc-2.12-1.192.el6.x86_64
> glibc-headers-2.12-1.192.el6.x86_64
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7322) Enable precompiled headers (on non-Windows)
[ https://issues.apache.org/jira/browse/MESOS-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7322: - Comment: was deleted (was: www.rtat.net) > Enable precompiled headers (on non-Windows) > --- > > Key: MESOS-7322 > URL: https://issues.apache.org/jira/browse/MESOS-7322 > Project: Mesos > Issue Type: Improvement > Components: cmake >Reporter: Joseph Wu >Priority: Major > Labels: mesosphere > > Support for precompiled headers was added in [MESOS-7226], but only on > Windows. Posix and Linux builds have additional sources with their own set > of problems (mostly namespace resolution conflict) that arise from using > precompiled headers. > This issue tracks progress on enabling precompiled headers on non-Windows > platforms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1693) Enable builds for ARM
[ https://issues.apache.org/jira/browse/MESOS-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1693: - Comment: was deleted (was: www.rtat.net) > Enable builds for ARM > - > > Key: MESOS-1693 > URL: https://issues.apache.org/jira/browse/MESOS-1693 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.19.1 >Reporter: Timothy St. Clair >Assignee: Timothy St. Clair >Priority: Major > Fix For: 0.20.0 > > > Enable building for ARM architecture. Current restriction support only x86 > based architectures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8447) Incomplete output of apply-reviews.py --dry-run
[
https://issues.apache.org/jira/browse/MESOS-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8447:
-
Comment: was deleted
(was: www.rtat.net)
> Incomplete output of apply-reviews.py --dry-run
> ---
>
> Key: MESOS-8447
> URL: https://issues.apache.org/jira/browse/MESOS-8447
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>Priority: Major
> Fix For: 1.6.0
>
>
> The script {{support/apply-reviews.py}} has a flag {{--dry-run}} which should
> dump the commands which would be performed. This flag is useful to e.g.,
> reorder patch chains or to manually resolve intermediate conflicts while
> still being able to pull a full chain.
> The output looks like this
> {noformat}
> % ./support/apply-reviews.py -r 62447 -c -n -3 --dry-run
> wget --no-check-certificate --no-verbose -O 62160.patch
> https://reviews.apache.org/r/62160/diff/raw/
> git apply --index 62160.patch --3way
> git commit --author "Benno Evers " -aF "62160.message"
> wget --no-check-certificate --no-verbose -O 62161.patch
> https://reviews.apache.org/r/62161/diff/raw/
> git apply --index 62161.patch --3way
> git commit --author "Benno Evers " -aF "62161.message"
> wget --no-check-certificate --no-verbose -O 62444.patch
> https://reviews.apache.org/r/62444/diff/raw/
> git apply --index 62444.patch --3way
> git commit --author "Benno Evers " -aF "62444.message"
> wget --no-check-certificate --no-verbose -O 62445.patch
> https://reviews.apache.org/r/62445/diff/raw/
> git apply --index 62445.patch --3way
> git commit --author "Benno Evers " -aF "62445.message"
> wget --no-check-certificate --no-verbose -O 62447.patch
> https://reviews.apache.org/r/62447/diff/raw/
> git apply --index 62447.patch --3way
> git commit --author "Benno Evers " -aF
> "62447.message"{noformat}
> Trying to replay that dry run leads to an error since the commands to create
> the commit message files are not printed.
> We should add these commands to the output.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7438) Double free or corruption when using parallel test runner
[
https://issues.apache.org/jira/browse/MESOS-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7438:
-
Comment: was deleted
(was: www.rtat.net)
> Double free or corruption when using parallel test runner
> -
>
> Key: MESOS-7438
> URL: https://issues.apache.org/jira/browse/MESOS-7438
> Project: Mesos
> Issue Type: Bug
> Components: test
>Reporter: Benjamin Mahler
>Priority: Major
> Labels: integration, mesosphere, tech-debt
>
> I observed the following when using the parallel test runner:
> {noformat}
> /home/bmahler/git/mesos/build/../support/mesos-gtest-runner.py
> --sequential=*ROOT_* ./mesos-tests
> ..
> *** Error in `/home/bmahler/git/mesos/build/src/.libs/mesos-tests': double
> free or corruption (out): 0x7fa818001310 ***
> === Backtrace: =
> /usr/lib64/libc.so.6(+0x7c503)[0x7fa87f27e503]
> /usr/lib64/libsasl2.so.3(+0x866d)[0x7fa880f0d66d]
> /usr/lib64/libsasl2.so.3(sasl_dispose+0x3b)[0x7fa880f1075b]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN5mesos8internal8cram_md527CRAMMD5AuthenticateeProcessD1Ev+0x5d)[0x7fa88708f67d]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN5mesos8internal8cram_md527CRAMMD5AuthenticateeProcessD0Ev+0x18)[0x7fa88708f734]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN5mesos8internal8cram_md520CRAMMD5AuthenticateeD1Ev+0xfb)[0x7fa88708a065]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN5mesos8internal8cram_md520CRAMMD5AuthenticateeD0Ev+0x18)[0x7fa88708a0b4]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN5mesos8internal5slave5Slave13_authenticateEv+0x67)[0x7fa8879ff579]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZZN7process8dispatchIN5mesos8internal5slave5SlaveEEEvRKNS_3PIDIT_EEMS6_FvvEENKUlPNS_11ProcessBaseEE_clESD_+0xe2)[0x7fa887a60b7a]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveEEEvRKNS0_3PIDIT_EEMSA_FvvEEUlS2_E_E9_M_invokeERKSt9_Any_dataS2_+0x37)[0x7fa887aa0efe]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZNKSt8functionIFvPN7process11ProcessBaseEEEclES2_+0x49)[0x7fad1177]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN7process11ProcessBase5visitERKNS_13DispatchEventE+0x2f)[0x7fab5063]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZNK7process13DispatchEvent5visitEPNS_12EventVisitorE+0x2e)[0x7fac0422]
> /home/bmahler/git/mesos/build/src/.libs/mesos-tests(_ZN7process11ProcessBase5serveERKNS_5EventE+0x2e)[0xb088c8]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(_ZN7process14ProcessManager6resumeEPNS_11ProcessBaseE+0x525)[0x7fab10d5]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(+0x5f1a880)[0x7faad880]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(+0x5f2ca8a)[0x7fabfa8a]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(+0x5f2c9ce)[0x7fabf9ce]
> /home/bmahler/git/mesos/build/src/.libs/libmesos-1.3.0.so(+0x5f2c958)[0x7fabf958]
> /usr/lib64/libstdc++.so.6(+0xb5230)[0x7fa87fb90230]
> /usr/lib64/libpthread.so.0(+0x7dc5)[0x7fa88040ddc5]
> /usr/lib64/libc.so.6(clone+0x6d)[0x7fa87f2f973d]
> {noformat}
> Not sure how reproducible this is, appears to occur in the authentication
> path of the agent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-138) When running Make (right at the end) it tries to copy mesos.py to a different directory, but the two directories are the same, so it fails
[ https://issues.apache.org/jira/browse/MESOS-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-138: Comment: was deleted (was: www.rtat.net) > When running Make (right at the end) it tries to copy mesos.py to a different > directory, but the two directories are the same, so it fails > -- > > Key: MESOS-138 > URL: https://issues.apache.org/jira/browse/MESOS-138 > Project: Mesos > Issue Type: Bug > Components: build > Environment: Red Hat (Amazon's AMI) >Reporter: Matthew Rathbone >Assignee: Benjamin Hindman >Priority: Minor > Labels: build-failure, python > > This bug is present in the generated Makefile.in (I ran > ./configure.template.amazon-linux-64) > The error is something like 'cp failed, the source and destination > directories are the same' > When you see the error, deleting this line from src/Makefile.in will fix it: > @HAS_PYTHON_TRUE@ @cp -pf $(srcdir)/python/src/mesos.py > python/src/mesos.py -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6901) Master build fails with g++ 4.8.5, g++ 4.9.4 and clang 3.8.0 on Ubuntu 16.04
[
https://issues.apache.org/jira/browse/MESOS-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-6901:
-
Comment: was deleted
(was: www.rtat.net)
> Master build fails with g++ 4.8.5, g++ 4.9.4 and clang 3.8.0 on Ubuntu 16.04
>
>
> Key: MESOS-6901
> URL: https://issues.apache.org/jira/browse/MESOS-6901
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.1.0
>Reporter: Frank Scholten
>Assignee: Kevin Klues
>Priority: Major
>
> When building with g++ 4.8.5 the configure script fails:
> {code}
> checking whether we can build usable Python eggs... cc1plus: warning: command
> line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
> [enabled by default]
> g++: error: unrecognized command line option '-Wdate-time'
> g++: error: unrecognized command line option '-fstack-protector-strong'
> error: command 'g++' failed with exit status 1
> configure: error: no
> ---
> It appears we were unable to build a usable native Python egg.
> There are two possible workarounds for this issue:
> 1. Disable python bindings by configuring with --disable-python.
> 2. Use an alternative Python installation that was built using
>the same build setup as Mesos.
> ---
> {code}
> When building with g++ 4.9.4 the build fails with a segmentation fault:
> {code}
> mv -f slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-utils.Tpo
> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-utils.Plo
> /bin/bash ../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"mesos\"
> -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"1.2.0\"
> -DPACKAGE_STRING=\"mesos\ 1.2.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"mesos\" -DVERSION=\"1.2.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_CXX11=1
> -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1
> -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1
> -DHAVE_LIBSASL2=1 -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1
> -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBZ=1
> -DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I. -I../../src -Werror
> -DLIBDIR=\"/usr/lib\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\"
> -DPKGDATADIR=\"/usr/share/mesos\" -DPKGMODULEDIR=\"/usr/lib/mesos/modules\"
> -I../../include -I../include -I../include/mesos -DPICOJSON_USE_INT64
> -D__STDC_FORMAT_MACROS -isystem ../3rdparty/boost-1.53.0
> -I../3rdparty/elfio-3.2 -I../3rdparty/glog-0.3.3/src
> -I../3rdparty/leveldb-1.4/include -I../../3rdparty/libprocess/include
> -I../3rdparty/nvml-352.79 -I../3rdparty/picojson-1.3.0
> -I../3rdparty/protobuf-2.6.1/src -I../../3rdparty/stout/include
> -I../3rdparty/zookeeper-3.4.8/src/c/include
> -I../3rdparty/zookeeper-3.4.8/src/c/generated -DHAS_AUTHENTICATION=1
> -I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
> -pthread -Wall -Wsign-compare -Wformat-security -fstack-protector-strong
> -fPIC -fPIE -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized
> -std=c++11 -MT
> slave/containerizer/mesos/io/libmesos_no_3rdparty_la-switchboard.lo -MD -MP
> -MF
> slave/containerizer/mesos/io/.deps/libmesos_no_3rdparty_la-switchboard.Tpo -c
> -o slave/containerizer/mesos/io/libmesos_no_3rdparty_la-switchboard.lo `test
> -f 'slave/containerizer/mesos/io/switchboard.cpp' || echo
> '../../src/'`slave/containerizer/mesos/io/switchboard.cpp
> libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
> -DPACKAGE_VERSION=\"1.2.0\" "-DPACKAGE_STRING=\"mesos 1.2.0\""
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
> -DVERSION=\"1.2.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_CXX11=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1 -DHAVE_APR_POOLS_H=1
> -DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1 -DHAVE_LIBSASL2=1
> -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
> -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBZ=1 -DHAVE_PYTHON=\"2.7\"
> -DMESOS_HAS_PYTHON=1 -I. -I../../src -Werror -DLIBDIR=\"/usr/lib\"
> -DPKGLIBEXECDIR=\"/usr/libexec/mesos\" -DPKGDATADIR=\"/usr/share/mesos\"
> -DPKGMODULEDIR=\"/usr/lib/mesos/modules\" -I../../include -I../include
> -I../include/mes
[jira] [Issue Comment Deleted] (MESOS-4772) TaskInfo/ExecutorInfo should include fine-grained ownership/namespacing
[ https://issues.apache.org/jira/browse/MESOS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-4772: - Comment: was deleted (was: www.rtat.net) > TaskInfo/ExecutorInfo should include fine-grained ownership/namespacing > --- > > Key: MESOS-4772 > URL: https://issues.apache.org/jira/browse/MESOS-4772 > Project: Mesos > Issue Type: Improvement > Components: security >Reporter: Adam B >Priority: Major > Labels: authorization, mesosphere, ownership, security > > We need a way to assign fine-grained ownership to tasks/executors so that > multi-user frameworks can tell Mesos to associate the task with a user > identity (rather than just the framework principal+role). Then, when an HTTP > user requests to view the task's sandbox contents, or kill the task, or list > all tasks, the authorizer can determine whether to allow/deny/filter the > request based on finer-grained, user-level ownership. > Some systems may want TaskInfo.owner to represent a group rather than an > individual user. That's fine as long as the framework sets the field to the > group ID in such a way that a group-aware authorizer can interpret it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8990) Build failure of the google-test dependency on Windows using MSVC.
[
https://issues.apache.org/jira/browse/MESOS-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8990:
-
Comment: was deleted
(was: www.rtat.net)
> Build failure of the google-test dependency on Windows using MSVC.
> --
>
> Key: MESOS-8990
> URL: https://issues.apache.org/jira/browse/MESOS-8990
> Project: Mesos
> Issue Type: Task
> Components: build
>Reporter: PhoebeHui
>Assignee: Andrew Schwartzmeyer
>Priority: Blocker
> Labels: agent, build, dependency, windows
> Fix For: 1.7.0
>
> Attachments: googletest-release-f66ab00.patch
>
>
> Build Mesos with msvc on windows currently blocked by the following issue,
> this issue has fixed on Goolgetest, could you help pick up it in Mesos?
> The next release msvc toolset will have this behavior.
> See background in
> [{color:#0066cc}https://github.com/google/googletest/issues/1616{color}], and
> the fix
> [{color:#0066cc}https://github.com/google/googletest/pull/1620{color}].
> The failures like:
> {noformat}
>
> d:\mesos\build_x64\3rdparty\googletest-1.8.0\src\googletest-1.8.0\googletest\include\gtest\gtest-printers.h(249,1):
> error C2593: 'operator <<' is ambiguous
> [D:\Mesos\build_x64\src\tests\mesos-tests.vcxproj]
> d:\mesos\build_x64\3rdparty\googletest-1.8.0\src\googletest-1.8.0\googletest\include\gtest\gtest-printers.h(249,1):
> error C2593: *os << value;
> [D:\Mesos\build_x64\src\tests\mesos-tests.vcxproj]
> d:\mesos\build_x64\3rdparty\googletest-1.8.0\src\googletest-1.8.0\googletest\include\gtest\gtest-printers.h(249,1):
> error C2593: ^ (compiling source file
> D:\Mesos\src\src\tests\command_executor_tests.cpp)
> [D:\Mesos\build_x64\src\tests\mesos-tests.vcxproj]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3709) Modularize the containerizer interface.
[ https://issues.apache.org/jira/browse/MESOS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3709: - Comment: was deleted (was: www.rtat.net) > Modularize the containerizer interface. > --- > > Key: MESOS-3709 > URL: https://issues.apache.org/jira/browse/MESOS-3709 > Project: Mesos > Issue Type: Epic > Components: containerization, modules >Reporter: Jie Yu >Assignee: haosdent >Priority: Major > Labels: containerizer, modularization, module > > So that people can implement their own containerizer as a module. That's more > efficient than having an external containerizer and shell out. The module > system also provides versioning support, this is definitely better than > unversioned external containerizer. > Design Doc: > https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1712) Automate disallowing of commits mixing mesos/libprocess/stout
[ https://issues.apache.org/jira/browse/MESOS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1712: - Comment: was deleted (was: www.rtat.net) > Automate disallowing of commits mixing mesos/libprocess/stout > - > > Key: MESOS-1712 > URL: https://issues.apache.org/jira/browse/MESOS-1712 > Project: Mesos > Issue Type: Bug > Components: reviewbot >Reporter: Vinod Kone >Assignee: Cody Maloney >Priority: Major > Fix For: 0.21.0 > > > For various reasons, we don't want to mix mesos/libprocess/stout changes into > a single commit. Typically, it is up to the reviewee/reviewer to catch this. > It wold be nice to automate this via the pre-commit hook . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4036) Install instructions for CentOS 6.6 lead to errors running `perf`.
[
https://issues.apache.org/jira/browse/MESOS-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-4036:
-
Comment: was deleted
(was: www.rtat.net)
> Install instructions for CentOS 6.6 lead to errors running `perf`.
> --
>
> Key: MESOS-4036
> URL: https://issues.apache.org/jira/browse/MESOS-4036
> Project: Mesos
> Issue Type: Improvement
> Environment: CentOS 6.6
>Reporter: Greg Mann
>Assignee: Alexander Rukletsov
>Priority: Minor
> Labels: integration, mesosphere, newbie
> Fix For: 1.8.0
>
>
> After using the current installation instructions in the getting started
> documentation, {{perf}} will not run on CentOS 6.6 because the version of
> elfutils included in devtoolset-2 is not compatible with the version of
> {{perf}} installed by {{yum}}. Installing and using devtoolset-3, however
> (http://linux.web.cern.ch/linux/scientific6/docs/softwarecollections.shtml)
> fixes this issue. This could be resolved by updating the getting started
> documentation to recommend installing devtoolset-3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7822) Adopt X509_check_host.
[
https://issues.apache.org/jira/browse/MESOS-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7822:
-
Comment: was deleted
(was: www.rtat.net)
> Adopt X509_check_host.
> --
>
> Key: MESOS-7822
> URL: https://issues.apache.org/jira/browse/MESOS-7822
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, security
>Reporter: James Peach
>Priority: Major
>
> {{libprocess}} is carrying custom hostname verification code, which uses
> deprecated OpenSSL API:
> {noformat}
> ../../../3rdparty/libprocess/src/openssl.cpp: In function ‘Try
> process::network::openssl::verify(const SSL*, const
> Option >&, const Option&)’:
> ../../../3rdparty/libprocess/src/openssl.cpp:677:42: warning: ‘unsigned char*
> ASN1_STRING_data(ASN1_STRING*)’ is deprecated [-Wdeprecated-declarations]
>current_name->d.dNSName));
> ^
> In file included from /usr/include/openssl/opensslconf.h:42:0,
> from /usr/include/openssl/bn.h:31,
> from /usr/include/openssl/asn1.h:24,
> from /usr/include/openssl/objects.h:916,
> from /usr/include/openssl/evp.h:27,
> from /usr/include/openssl/x509.h:23,
> from /usr/include/openssl/ssl.h:50,
> from ../../../3rdparty/libprocess/src/openssl.hpp:16,
> from ../../../3rdparty/libprocess/src/openssl.cpp:13:
> /usr/include/openssl/asn1.h:553:1: note: declared here
> DEPRECATEDIN_1_1_0(unsigned char *ASN1_STRING_data(ASN1_STRING *x))
> ^
> {noformat}
> We should replace this (optionally with a OpenSSL version check) with a call
> to
> [X509_check_host|https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html]
> which is available since OpenSSL 1.0.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-864) Eliminate the use of internal stdlibc++ templates for achieving libc++ compatiblity
[ https://issues.apache.org/jira/browse/MESOS-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-864: Comment: was deleted (was: www.rtat.net) > Eliminate the use of internal stdlibc++ templates for achieving libc++ > compatiblity > > > Key: MESOS-864 > URL: https://issues.apache.org/jira/browse/MESOS-864 > Project: Mesos > Issue Type: Improvement > Components: build, libprocess >Affects Versions: 0.14.2 > Environment: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM > 3.3svn), libc++ (_LIBCPP_VERSION) 1101 >Reporter: Till Toenshoff >Assignee: Benjamin Hindman >Priority: Minor > Labels: build, clang, libc++, libprocess, stdlibc++ > Fix For: 0.17.0 > > > When attempting to build libprocess against libc++ most pitfalls are simply > namespace related (::tr1) but some are harder to come by. > One example is the use of std::tr1::_Bind within deferred.hpp. > [3rdparty/libprocess/include/process/deferred.hpp] > For the specific example, a comment was given for reasoning the design choice: > The result of invoking the 'defer' routines is actually an internal > type, effectively just a wrapper around the result of invoking > 'std::tr1::bind'. However, we want the result of bind to be castable to a > 'Deferred' but we don't want anyone to be able to create a 'Deferred' so we > use a level-of-indirection via this type. > How could we solve this without deriving directly from _Bind? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9170) Zookeeper doesn't compile with newer gcc due to format error
[ https://issues.apache.org/jira/browse/MESOS-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9170: - Comment: was deleted (was: www.rtat.net) > Zookeeper doesn't compile with newer gcc due to format error > > > Key: MESOS-9170 > URL: https://issues.apache.org/jira/browse/MESOS-9170 > Project: Mesos > Issue Type: Bug > Components: build >Reporter: Kapil Arya >Assignee: Kapil Arya >Priority: Major > Labels: build, integration > Fix For: 1.4.3, 1.5.2, 1.6.2, 1.7.0 > > > RR: https://reviews.apache.org/r/68370/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9658) Make command-line and/or environment variables be able to unset a flag.
[
https://issues.apache.org/jira/browse/MESOS-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9658:
-
Comment: was deleted
(was: www.rtat.net)
> Make command-line and/or environment variables be able to unset a flag.
> ---
>
> Key: MESOS-9658
> URL: https://issues.apache.org/jira/browse/MESOS-9658
> Project: Mesos
> Issue Type: Improvement
>Reporter: Chun-Hung Hsiao
>Priority: Major
> Labels: integration
>
> Currently if a Mesos master/agent command-line flag is of type {{Option}},
> the only way to leave it as {{None}} is to unset the corresponding {{MESOS_}}
> environment variable and don't specify the flag. Although this works, it
> would be nice if the user could:
> 1. Override environment variable through command-line flags, e.g.
> {{--feature_flag=none}}.
> 2. Override environment variable with another value, e.g.,
> {{MESOS_FEATURE_FLAG=none}}. This is especially useful if users are managing
> Mesos through systemd and specifying flags through environment files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8923) Naked expectations can lead to flaky tests.
[
https://issues.apache.org/jira/browse/MESOS-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8923:
-
Comment: was deleted
(was: www.rtat.net)
> Naked expectations can lead to flaky tests.
> ---
>
> Key: MESOS-8923
> URL: https://issues.apache.org/jira/browse/MESOS-8923
> Project: Mesos
> Issue Type: Task
> Components: test
>Reporter: Alexander Rukletsov
>Priority: Major
> Labels: integration, mesosphere
>
> There are several cases when too general expectations can be triggered by
> related but not targeted events. Examples:
> 1. Resent task status update before ack due to clock manipulation
> 2. Advancing clock with {{registration_backoff_factor}} to ensure successful
> registration might lead to a case where the first agent resends registration
> request and hence satisfies the expectation for the second agent.
> A possible solution would be extensive use of matchers and extra primitives
> wrapping them. For example, a possible approach to 1. is
> https://reviews.apache.org/r/63577/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3485) Make hook execution order deterministic
[
https://issues.apache.org/jira/browse/MESOS-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-3485:
-
Comment: was deleted
(was: www.rtat.net)
> Make hook execution order deterministic
> ---
>
> Key: MESOS-3485
> URL: https://issues.apache.org/jira/browse/MESOS-3485
> Project: Mesos
> Issue Type: Improvement
> Components: modules
>Reporter: Felix Abecassis
>Assignee: haosdent
>Priority: Major
>
> Currently, when using multiple hooks of the same type, the execution order is
> implementation-defined.
> This is because in src/hook/manager.cpp, the list of available hooks is
> stored in a {{hashmap}}. A hashmap is probably unnecessary for
> this task since the number of hooks should remain reasonable. A data
> structure preserving ordering should be used instead to allow the user to
> predict the execution order of the hooks. I suggest that the execution order
> should be the order in which hooks are specified with {{--hooks}} when
> starting an agent/master.
> This will be useful when combining multiple hooks after MESOS-3366 is done.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4693) Variable shadowing in HookManager::slavePreLaunchDockerHook
[
https://issues.apache.org/jira/browse/MESOS-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-4693:
-
Comment: was deleted
(was: www.rtat.net)
> Variable shadowing in HookManager::slavePreLaunchDockerHook
> ---
>
> Key: MESOS-4693
> URL: https://issues.apache.org/jira/browse/MESOS-4693
> Project: Mesos
> Issue Type: Bug
> Components: modules
>Affects Versions: 0.27.0
>Reporter: Kevin Devroede
>Assignee: Kevin Devroede
>Priority: Major
> Fix For: 0.27.2, 0.28.0
>
>
> It looks like the {{name}} parameter in
> {{HookManager::slavePreLaunchDockerHook}} is shadowed by the hook name
> defined in the {{foreach (const string& name, availableHooks.keys())}}.
> Due to this, the hook receives its own name as a parameter instead of the
> container name. It seems to be the only method of HookManager affected by
> this shadowing.
> See: https://github.com/apache/mesos/blob/0.27.0/src/hook/manager.cpp#L203
> If that's really a bug, I'd be happy to submit a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7343) Add a ReviewBot for testing patches on Windows
[ https://issues.apache.org/jira/browse/MESOS-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7343: - Comment: was deleted (was: www.rtat.net) > Add a ReviewBot for testing patches on Windows > -- > > Key: MESOS-7343 > URL: https://issues.apache.org/jira/browse/MESOS-7343 > Project: Mesos > Issue Type: Improvement > Components: reviewbot > Environment: Windows 10 >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer >Priority: Major > Labels: microsoft, windows > Fix For: 1.4.0 > > > A major hindrance to development of Mesos for Windows is that, since the > platform support is so new, no tests their patches on Windows. Frequently > this causes upstream commits to master to break the Windows build (a recent > notable occasion was commit 5f159cdcb), which interrupts Windows developers > (read: me) in order to fix the build. Much of the problem is due to broken > processes failing to catch human error. > One process we can immediately fix is the ReviewBot, which tests uploaded > patches for Ubuntu. Adding the same functionality but for Windows will go a > long way toward preventing upstream build breaks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8021) Update HTTP scheduler library to allow for modularized authenticatee.
[ https://issues.apache.org/jira/browse/MESOS-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-8021: - Comment: was deleted (was: www.rtat.net) > Update HTTP scheduler library to allow for modularized authenticatee. > - > > Key: MESOS-8021 > URL: https://issues.apache.org/jira/browse/MESOS-8021 > Project: Mesos > Issue Type: Improvement > Components: HTTP API, modules, scheduler api, security >Reporter: Till Toenshoff >Assignee: Till Toenshoff >Priority: Major > Labels: mesosphere, modularization, scheduler, security > Fix For: 1.5.0 > > > Allow the scheduler library to load an HTTP authenticatee module providing > custom mechanisms for authentication. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9266) Whenever our packaging tasks trigger errors we run into permission problems.
[
https://issues.apache.org/jira/browse/MESOS-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9266:
-
Comment: was deleted
(was: www.rtat.net)
> Whenever our packaging tasks trigger errors we run into permission problems.
>
>
> Key: MESOS-9266
> URL: https://issues.apache.org/jira/browse/MESOS-9266
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Till Toenshoff
>Assignee: Jie Yu
>Priority: Minor
> Labels: mesosphere, packaging, rainbow-worriers-task
> Fix For: 1.7.1, 1.8.0
>
>
> As shown in MESOS-9238, failures within our packaging cause permission
> failures on cleanup.
> {noformat}
> cleanup
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/Mesos-Docker-CentOS/centos7/.cache':
> Permission denied
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/Mesos-Docker-CentOS/centos7/rpmbuild/SRPMS':
> Permission denied
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/Mesos-Docker-CentOS/centos7/rpmbuild/BUILDROOT/mesos-1.8.0-0.1.pre.20180915git4805a47.el7.x86_64/var/lib/mesos':
> Permission denied
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/Mesos-Docker-CentOS/centos7/rpmbuild/BUILDROOT/mesos-1.8.0-0.1.pre.20180915git4805a47.el7.x86_64/var/log/mesos':
> Permission denied
> {noformat}
> We should clean that up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4274) libprocess build fail with libhttp-parser >= 2.0
[
https://issues.apache.org/jira/browse/MESOS-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-4274:
-
Comment: was deleted
(was: www.rtat.net)
> libprocess build fail with libhttp-parser >= 2.0
>
>
> Key: MESOS-4274
> URL: https://issues.apache.org/jira/browse/MESOS-4274
> Project: Mesos
> Issue Type: Bug
> Components: build, libprocess
>Affects Versions: 0.26.0
> Environment: debian 8 with package {{libhttp-parser-dev}} installed
> and libprocess configured with {{--disable-bundled}}
>Reporter: Jocelyn De La Rosa
>Assignee: Jocelyn De La Rosa
>Priority: Minor
> Labels: build-failure, compile-error, easyfix
> Fix For: 0.27.0
>
>
> Since mesos 0.26 libprocess does not compile if the libhttp-parser version is
> >= 2.0.
> I traced back the issue to the commit {{d347bf56c807d}} that added URL to the
> {{http::Request}} but forgot to modify the {{#if HTTP_PARSER_VERSION MAJORS
> >=2}} parts in {{3rdparty/libprocess/src/decoder.hpp}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4201) APR_LIBS and SVN_LIBS varibles defined as paths to the releated libriaries are incorrectly added to a varialbe that lists directories (STOUT_TEST_LIB_DIRS).
[ https://issues.apache.org/jira/browse/MESOS-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-4201: - Comment: was deleted (was: www.rtat.net) > APR_LIBS and SVN_LIBS varibles defined as paths to the releated libriaries > are incorrectly added to a varialbe that lists directories > (STOUT_TEST_LIB_DIRS). > > > Key: MESOS-4201 > URL: https://issues.apache.org/jira/browse/MESOS-4201 > Project: Mesos > Issue Type: Bug > Components: cmake >Reporter: Diana Arroyo >Priority: Minor > > In StoutTestsConfigure.cmake there APR_LIBS and SVN_LIBS variable sthat are > are incorrectly defined to the STOUT_TEST_LIB_DIRS. The variables APR_LIBS > and SVN_LIBS are not dirs. but instead full paths to the library file. Most > likely the fix is to move the variables should be added to the > STOUT_TEST_LIBS variable but will leave it up to the owner of this work item > to decide the fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5094) Remove Fetcher in MesosContainerizer::create interface
[ https://issues.apache.org/jira/browse/MESOS-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5094: - Comment: was deleted (was: www.rtat.net) > Remove Fetcher in MesosContainerizer::create interface > -- > > Key: MESOS-5094 > URL: https://issues.apache.org/jira/browse/MESOS-5094 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent >Priority: Major > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8826) ReaperProcess depends on clock manipulation.
[
https://issues.apache.org/jira/browse/MESOS-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8826:
-
Comment: was deleted
(was: www.rtat.net)
> ReaperProcess depends on clock manipulation.
>
>
> Key: MESOS-8826
> URL: https://issues.apache.org/jira/browse/MESOS-8826
> Project: Mesos
> Issue Type: Task
> Components: libprocess
>Reporter: Andrei Budnik
>Priority: Major
> Labels: integration, mesosphere
>
> After making composing containerizer as a default containerizer in tests by
> setting a value `mesos,docker` for `containerizers` flag in
> `MesosTest::CreateSlaveFlags()`, some tests started to endlessly wait for
> recovery completion after starting slave with paused clocks.
> Recovery process for a docker c'zer uses `subprocess()` to spawn `docker ps
> -a` subprocess and [subscribes for its
> termination|https://github.com/apache/mesos/blob/ca21ca82071f2c53d5817424569977728260da65/src/docker/docker.cpp#L1466-L1467].
> As a reaper process [uses
> `delay()`|https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/reap.cpp#L112],
> this leads to a hanging recovery process for the docker c'zer, when the
> libprocess' clocks are paused.
> A possible [solution might
> be|https://github.com/abudnik/mesos/commit/246958b8c942c150b2da778c8ab0f351be235992]
> using a single dedicated thread that doesn't use libprocess clocks and
> periodically iterates over pids and calls `waitpid` for each of them.
> In addition, we can introduce one more dedicated thread that calls
> `waitpid(-1)` to wait for termination of children processes, so that we can
> get rid of
> {code:java}
> while (someEvent.isPending()) {
> Clock::advance(process::MAX_REAP_INTERVAL());
> Clock::settle();
> }{code}
> pattern in tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8913) Resource provider manager registry leaks file descriptors into executors.
[
https://issues.apache.org/jira/browse/MESOS-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8913:
-
Comment: was deleted
(was: www.rtat.net)
> Resource provider manager registry leaks file descriptors into executors.
> -
>
> Key: MESOS-8913
> URL: https://issues.apache.org/jira/browse/MESOS-8913
> Project: Mesos
> Issue Type: Bug
> Components: agent, security, storage
>Affects Versions: 1.6.0
>Reporter: James Peach
>Assignee: Benjamin Bannier
>Priority: Major
> Fix For: 1.7.0
>
>
> I have an executor that closes unknown file descriptors when it starts up:
> {noformat}
> 2018/05/14 20:54:43.210293 util_linux.go:65: closing extraneous fd 126
> (/srv/mesos/work/meta/slaves/30d57187-99b4-4e63-aba8-f425a80a6702-S8/resource_provider_registry/08.log)
> 2018/05/14 20:54:43.210345 util_linux.go:47: unable to call fcntl() to get fd
> options for fd 3: errno bad file descriptor
> 2018/05/14 20:54:43.210385 util_linux.go:65: closing extraneous fd 321
> (/srv/mesos/work/meta/slaves/30d57187-99b4-4e63-aba8-f425a80a6702-S8/resource_provider_registry/LOG)
> 2018/05/14 20:54:43.210438 util_linux.go:65: closing extraneous fd 322
> (/srv/mesos/work/meta/slaves/30d57187-99b4-4e63-aba8-f425a80a6702-S8/resource_provider_registry/LOCK)
> 2018/05/14 20:54:43.210501 util_linux.go:65: closing extraneous fd 324
> (/srv/mesos/work/meta/slaves/30d57187-99b4-4e63-aba8-f425a80a6702-S8/resource_provider_registry/MANIFEST-06)
> {noformat}
> It is closing leveldb descriptors leaked by the resource provider manager
> registry in the agent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7938) CMake build should give Libevent a hint to use HomeBrew OpenSSL on OSX
[
https://issues.apache.org/jira/browse/MESOS-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7938:
-
Comment: was deleted
(was: www.rtat.net)
> CMake build should give Libevent a hint to use HomeBrew OpenSSL on OSX
> --
>
> Key: MESOS-7938
> URL: https://issues.apache.org/jira/browse/MESOS-7938
> Project: Mesos
> Issue Type: Improvement
> Components: cmake
>Reporter: Joseph Wu
>Priority: Major
>
> The CMake build currently uses standard CMake modules (i.e. {{find_package}})
> to find OpenSSL and Libevent installed on the system. On OSX however, CMake
> will generally find the system installed version of OpenSSL rather than the
> more up-to-date HomeBrew package.
> We should consider giving this hint to the Libevent package finder:
> {code}
> -DOPENSSL_ROOT_DIR=`brew --prefix openssl`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-58) Migrate build system to Autotools (Automake and Libtool)
[ https://issues.apache.org/jira/browse/MESOS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-58: --- Comment: was deleted (was: www.rtat.net) > Migrate build system to Autotools (Automake and Libtool) > > > Key: MESOS-58 > URL: https://issues.apache.org/jira/browse/MESOS-58 > Project: Mesos > Issue Type: Improvement > Components: build >Reporter: Andy Konwinski >Assignee: Benjamin Hindman >Priority: Major > > Ben has been leading the effort to move the build system to Autotools. This > should lead to better dependency management, cleaner and easier to understand > human written build input, and a faster build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1009) src/demangle.cc:170:13: error: comparison between pointer and integer ('const char *' and 'int')
[
https://issues.apache.org/jira/browse/MESOS-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-1009:
-
Comment: was deleted
(was: www.rtat.net)
> src/demangle.cc:170:13: error: comparison between pointer and integer ('const
> char *' and 'int')
>
>
> Key: MESOS-1009
> URL: https://issues.apache.org/jira/browse/MESOS-1009
> Project: Mesos
> Issue Type: Bug
> Components: build
> Environment: Ubuntu 13.10
>Reporter: Vinson Lee
>Assignee: Bernd Mathiske
>Priority: Major
> Fix For: 0.18.0
>
>
> Building with clang 3.5svn.
> src/demangle.cc:170:13: error: comparison between pointer and integer ('const
> char *' and 'int')
> if (str == '\0') {
> ~~~ ^
> src/demangle.cc:226:26: error: comparison between pointer and integer ('const
> char *' and 'int')
> if (state->mangled_cur == '\0') {
> ~~ ^
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3268) apply-review.sh crashes with non ASCII char
[ https://issues.apache.org/jira/browse/MESOS-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3268: - Comment: was deleted (was: www.rtat.net) > apply-review.sh crashes with non ASCII char > --- > > Key: MESOS-3268 > URL: https://issues.apache.org/jira/browse/MESOS-3268 > Project: Mesos > Issue Type: Bug > Components: reviewbot >Reporter: José Guilherme Vanz >Assignee: Gastón Kleiman >Priority: Minor > Labels: mesosphere > > There is an issue in the apply-review script when user name field has some > non ascii char. E.g.: > Bad patch! > Reviews applied: [37468] > Failed command: ./support/apply-review.sh -n -r 37468 > Error: > 2015-08-14 04:22:30 URL:https://reviews.apache.org/r/37468/diff/raw/ > [23334/23334] -> "37468.patch" [1] > Traceback (most recent call last): > File "./support/jsonurl.py", line 25, in > print data > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position > 3: ordinal not in range(128) > Successfully applied: Removed allocation types to mesos::master namespace > The allocation-related types was moved to mesos::master namespace. > MESOS-2516 > Review: https://reviews.apache.org/r/37468 > fatal: empty ident name (for ) not allowed > Failed to commit patch > In this example, the problem was caused because the full name of the user has > the "é" char. For simulate the problem you can run the following shell script: > `AUTHOR_NAME=$(./support/jsonurl.py > https://reviews.apache.org/api/users/jvanz/ user fullname)` > (This is my user, I removed the non ascii char to send more patches) > The problem is when the result of the python script is kept in the variable. > If you call the python script without store the result in a variable > everything works fine. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1889: - Comment: was deleted (was: www.rtat.net) > Create an Authenticator Module > -- > > Key: MESOS-1889 > URL: https://issues.apache.org/jira/browse/MESOS-1889 > Project: Mesos > Issue Type: Improvement > Components: modules >Reporter: Till Toenshoff >Assignee: Till Toenshoff >Priority: Major > Fix For: 0.21.0 > > > h4. Motivation > Allow for third parties to quickly develop and plug-in new authentication > methods. The modularized Authenticator API will lower the barrier for the > community to provide new methods to Mesos. An example for such additional, > next step module could be PAM (LDAP, MySQL, NIS, UNIX) backed authentication. > cyrus-sasl2 itself already offers more than a half a dozen mechanisms via its > standard plugins and these could be triggered by additional Authenticator / > Authenticatee modules. cyrus-sasl2 does support even more mechanisms when > being custom built (about a full dozen) but we do not want to bundle > cyrus-sasl2 to enforce custom builds. Alternative authentication (especially > non-SASL based) methods may bring in new dependencies that we don't want to > enforce on all of our users. Mesos users may be required to use custom > authentication techniques due to strict security policies. > h4. Breakdown > - [Interface Design|https://issues.apache.org/jira/browse/MESOS-1891] > - [Location and Naming|https://issues.apache.org/jira/browse/MESOS-1893] > - [Integration|https://issues.apache.org/jira/browse/MESOS-1966] > - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7001) Implement a JWT authenticator
[
https://issues.apache.org/jira/browse/MESOS-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7001:
-
Comment: was deleted
(was: www.rtat.net)
> Implement a JWT authenticator
> -
>
> Key: MESOS-7001
> URL: https://issues.apache.org/jira/browse/MESOS-7001
> Project: Mesos
> Issue Type: Task
> Components: modules, security
>Reporter: Greg Mann
>Assignee: Jan Schlicht
>Priority: Major
> Labels: module, security
> Fix For: 1.3.0
>
>
> A JSON web token (JWT) authenticator module should be added to authenticate
> executors which use default credentials generated by the agent. This module
> will be loaded as an HTTP authenticator by default when
> {{--authenticate_http_executors}} is set, unless HTTP authenticators are
> specified explicitly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7866) CMake build system improvements
[ https://issues.apache.org/jira/browse/MESOS-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7866: - Comment: was deleted (was: www.rtat.net) > CMake build system improvements > --- > > Key: MESOS-7866 > URL: https://issues.apache.org/jira/browse/MESOS-7866 > Project: Mesos > Issue Type: Epic > Components: build >Reporter: Joseph Wu >Assignee: Joseph Wu >Priority: Major > Labels: build, cmake, mesosphere > > This is a followup Epic for the [CMake > epic|https://issues.apache.org/jira/browse/MESOS-898]. > This includes items that will be tackled after we officially switch the build > system from Autotools to CMake. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-2982) Make Check Fails on RHEL 6
[ https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-2982: - Comment: was deleted (was: www.rtat.net) > Make Check Fails on RHEL 6 > -- > > Key: MESOS-2982 > URL: https://issues.apache.org/jira/browse/MESOS-2982 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.22.1 > Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 > 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux Server release 6.6 (Santiago) >Reporter: Miguel Bernadin >Priority: Major > > After downloading Mesos 22.1 and attemted to build it, I've encountered > failures on the build process below: > FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam > = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) > [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) > [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = > mesos::internal::slave::CgroupsCpushareIsolatorProcess > userdel: user 'mesos.test.unprivileged.user' does not exist > [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup > -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or > directory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4713) ReviewBot should not fail hard if there are circular dependencies in a review chain
[ https://issues.apache.org/jira/browse/MESOS-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-4713: - Comment: was deleted (was: www.rtat.net) > ReviewBot should not fail hard if there are circular dependencies in a review > chain > --- > > Key: MESOS-4713 > URL: https://issues.apache.org/jira/browse/MESOS-4713 > Project: Mesos > Issue Type: Task > Components: reviewbot >Reporter: Vinod Kone >Assignee: Vinod Kone >Priority: Major > Fix For: 0.28.0 > > > Instead of failing hard, ReviewBot should post an error to the review that a > circular dependency is detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1029) lib stout compile errors on Ubuntu 13.10 with Clang 3.5
[ https://issues.apache.org/jira/browse/MESOS-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1029: - Comment: was deleted (was: www.rtat.net) > lib stout compile errors on Ubuntu 13.10 with Clang 3.5 > --- > > Key: MESOS-1029 > URL: https://issues.apache.org/jira/browse/MESOS-1029 > Project: Mesos > Issue Type: Bug > Components: build, libprocess > Environment: Ubuntu 13.10 > Clang 3.5 (built from source) >Reporter: Bernd Mathiske >Assignee: Bernd Mathiske >Priority: Minor > Labels: newbie > Fix For: 0.18.0 > > Original Estimate: 0h > Remaining Estimate: 0h > > Depends on MESOS-1009. Will not show unless the former is fixed first. > Fix for this issue is available, will submit for review. > Compile errors: > ../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp:730:18: error: > 'va_start' has undefined behavior with > reference types [-Werror,-Wvarargs] > va_start(args, fmt); > ^ > /root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: > expanded from macro 'va_start' > #define va_start(ap, param) __builtin_va_start(ap, param) >^ > ../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp:727:60: note: > parameter of type 'const std::string &' > (aka 'const basic_string &') is declared here > inline Try shell(std::ostream* os, const std::string& fmt, ...) > ../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp:402:18: > error: 'va_start' has undefined behavior with > reference types [-Werror,-Wvarargs] > va_start(args, fmt); > ^ > /root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: > expanded from macro 'va_start' > #define va_start(ap, param) __builtin_va_start(ap, param) >^ > ../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp:399:51: > note: parameter of type 'const std::string &' > (aka 'const basic_string &') is declared here > inline Try format(const std::string& fmt, ...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4538) Run installed test binaries in CI
[
https://issues.apache.org/jira/browse/MESOS-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-4538:
-
Comment: was deleted
(was: www.rtat.net)
> Run installed test binaries in CI
> -
>
> Key: MESOS-4538
> URL: https://issues.apache.org/jira/browse/MESOS-4538
> Project: Mesos
> Issue Type: Improvement
> Components: build
>Reporter: Benjamin Bannier
>Priority: Minor
>
> With MESOS-3608 we add functionality to optionally install mesos-test
> binaries. We should update the CI setup to run installed tests as well as
> in-tree tests.
> Since the installation of the test binaries is opt-in we need to explicitly
> enable this for distcheck by adding {{--enable-tests-install}} to
> {{DISTCHECK_CONFIGURE_FLAGS}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-2027) make distcheck on OSX 10.10
[
https://issues.apache.org/jira/browse/MESOS-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-2027:
-
Comment: was deleted
(was: www.rtat.net)
> make distcheck on OSX 10.10
> ---
>
> Key: MESOS-2027
> URL: https://issues.apache.org/jira/browse/MESOS-2027
> Project: Mesos
> Issue Type: Bug
> Components: build
> Environment: OSX 10.10
>Reporter: Till Toenshoff
>Assignee: Till Toenshoff
>Priority: Minor
>
> It seems our ZooKeeper Yosemite hotfix does not correctly get applied when
> doing a make distcheck on OSX 10.10.
> {noformat}
> config.status: executing depfiles commands
> /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
> if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
> -I./include -I./tests -I./generated -Wall -Werror -g -O2 -D_GNU_SOURCE -MT
> zookeeper.lo -MD -MP -MF ".deps/zookeeper.Tpo" -c -o zookeeper.lo `test -f
> 'src/zookeeper.c' || echo './'`src/zookeeper.c; \
> then mv -f ".deps/zookeeper.Tpo" ".deps/zookeeper.Plo"; else rm -f
> ".deps/zookeeper.Tpo"; exit 1; fi
> gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./tests -I./generated -Wall
> -Werror -g -O2 -D_GNU_SOURCE -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo
> -c src/zookeeper.c -fno-common -DPIC -o zookeeper.o
> In file included from src/zookeeper.c:27:
> In file included from ./include/zookeeper.h:34:
> ./include/recordio.h:76:9: error: expected ')'
> int64_t htonll(int64_t v);
>^
> /usr/include/sys/_endian.h:141:25: note: expanded from macro 'htonll'
> #define htonll(x) __DARWIN_OSSwapInt64(x)
>^
> /usr/include/libkern/_OSByteOrder.h:78:30: note: expanded from macro
> '__DARWIN_OSSwapInt64'
>(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
> ^
> ./include/recordio.h:76:9: note: to match this '('
> /usr/include/sys/_endian.h:141:25: note: expanded from macro 'htonll'
> #define htonll(x) __DARWIN_OSSwapInt64(x)
>^
> /usr/include/libkern/_OSByteOrder.h:78:5: note: expanded from macro
> '__DARWIN_OSSwapInt64'
>(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
>^
> In file included from src/zookeeper.c:27:
> In file included from ./include/zookeeper.h:34:
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9414) Rework FindPackageHelper to allow for locating xxx_ROOT_DIR.
[ https://issues.apache.org/jira/browse/MESOS-9414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9414: - Comment: was deleted (was: www.rtat.net) > Rework FindPackageHelper to allow for locating xxx_ROOT_DIR. > > > Key: MESOS-9414 > URL: https://issues.apache.org/jira/browse/MESOS-9414 > Project: Mesos > Issue Type: Improvement > Components: build, cmake >Affects Versions: 1.8.0 >Reporter: Till Toenshoff >Priority: Minor > Labels: cmake, unbundled-dependencies > > With the introduction of unbundled libevent, libarchive and leveldb CMake > builds, code duplication within the respective FindXXX.cmake modules became > apparent and a refactoring seems adequate. > See this TODO: > https://github.com/apache/mesos/blob/e6b507b6469553725c98b953f9578ab3f1a40b93/3rdparty/cmake/FindLIBARCHIVE.cmake#L19 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7190) Update endpoint handlers to use 'ObjectApprover'
[
https://issues.apache.org/jira/browse/MESOS-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7190:
-
Comment: was deleted
(was: www.rtat.net)
> Update endpoint handlers to use 'ObjectApprover'
>
>
> Key: MESOS-7190
> URL: https://issues.apache.org/jira/browse/MESOS-7190
> Project: Mesos
> Issue Type: Improvement
> Components: security
>Reporter: Greg Mann
>Priority: Major
> Labels: authorization, mesosphere, security
>
> The {{ObjectApprover}}-based interface for the authorizer has been
> introduced, but not all handlers make use of this new functionality (i.e.,
> {{Slave::Http::flags()}}. We should consider migrating all authorization code
> to use {{getObjectApprover}}, and deprecating the older {{authorized()}}
> interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-64) Building outside of src directory broken by MESOS-49
[ https://issues.apache.org/jira/browse/MESOS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-64: --- Comment: was deleted (was: www.rtat.net) > Building outside of src directory broken by MESOS-49 > > > Key: MESOS-64 > URL: https://issues.apache.org/jira/browse/MESOS-64 > Project: Mesos > Issue Type: Bug > Components: build >Reporter: Andy Konwinski >Assignee: Charles Reiss >Priority: Minor > Attachments: > 0001-Use-SRCDIR-consistently-in-java-library-build-rule.patch > > > The MESOS-49 patch broke out of source builds (if the Java API is built) > because it didn't use $(SRCDIR) in a couple places. > A patch for this bug (and the above description) was submitted by Charles > Reiss via review board at https://reviews.apache.org/r/2661 > Thanks Charles! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6959) Separate the mesos-containerizer binary into a static binary, which only depends on stout
[
https://issues.apache.org/jira/browse/MESOS-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-6959:
-
Comment: was deleted
(was: www.rtat.net)
> Separate the mesos-containerizer binary into a static binary, which only
> depends on stout
> -
>
> Key: MESOS-6959
> URL: https://issues.apache.org/jira/browse/MESOS-6959
> Project: Mesos
> Issue Type: Task
> Components: cmake
>Reporter: Joseph Wu
>Assignee: Andrew Schwartzmeyer
>Priority: Major
> Labels: cmake, mesosphere, microsoft
>
> The {{mesos-containerizer}} binary currently has [three
> commands|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/main.cpp#L46-L48]:
> *
> [MesosContainerizerLaunch|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/launch.cpp]
> *
> [MesosContainerizerMount|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/mount.cpp]
> *
> [NetworkCniIsolatorSetup|https://github.com/apache/mesos/blob/6cf3a94a52e87a593c9cba373bf433cfc4178639/src/slave/containerizer/mesos/isolators/network/cni/cni.cpp#L1776-L1997]
> These commands are all heavily dependent on stout, and have no need to be
> linked to libprocess. In fact, adding an erroneous call to
> {{process::initialize}} (either explicitly, or by accidentally using a
> libprocess method) will break {{mesos-containerizer}} can cause several Mesos
> containerizer tests to fail. (The tasks fail to launch, saying {{Failed to
> synchronize with agent (it's probably exited)}}).
> Because this binary only depends on stout, we can separate it from the other
> source files and make this a static binary.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7296) CMake 2.8.10 does not support TIMESTAMP
[ https://issues.apache.org/jira/browse/MESOS-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7296: - Comment: was deleted (was: www.rtat.net) > CMake 2.8.10 does not support TIMESTAMP > --- > > Key: MESOS-7296 > URL: https://issues.apache.org/jira/browse/MESOS-7296 > Project: Mesos > Issue Type: Bug > Components: cmake > Environment: Anywhere with CMake 2.x instead of 3.x (specifically > 2.8.10). >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer >Priority: Trivial > Labels: build > Fix For: 1.5.0 > > > The patch https://reviews.apache.org/r/57052/ moved the build time and date > info out of compile definitions and into a build file. While testing, an > existent bug was discovered where the CMake command `string(TIMESTAMP > BUILD_TIME "%s" UTC)` is unsupported with CMake 2.8.10. Instead of replacing > the variable with the time, it replaces with with "%s". > This is not a Linux vs Windows bug. This is specifically unsupported in > 2.8.10. Configuring with `cmake3` does not reproduce the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5523) ValueError: A 0.7-series setuptools cannot be installed with distribute. Found one at /usr/lib/python2.7/dist-packages
[
https://issues.apache.org/jira/browse/MESOS-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-5523:
-
Comment: was deleted
(was: www.rtat.net)
> ValueError: A 0.7-series setuptools cannot be installed with distribute.
> Found one at /usr/lib/python2.7/dist-packages
> --
>
> Key: MESOS-5523
> URL: https://issues.apache.org/jira/browse/MESOS-5523
> Project: Mesos
> Issue Type: Bug
> Components: build
> Environment: Ubuntu 16.04
>Reporter: Vinson Lee
>Priority: Major
> Labels: build
>
> {noformat}
> $ make
> [...]
> Building protobuf Python egg ...
> cd ../3rdparty/libprocess/3rdparty/protobuf-2.5.0/python &&
> \
> CC="gcc"\
> CXX="g++" \
> CFLAGS="-g1 -O0 -Wno-unused-local-typedefs" \
> CXXFLAGS="-g1 -O0 -Wno-unused-local-typedefs -std=c++11"
> \
> PYTHONPATH=build/3rdparty/distribute-0.6.26 \
> /usr/bin/python setup.py build bdist_egg
> Traceback (most recent call last):
> File "setup.py", line 11, in
> from setuptools import setup, Extension
> File "build/3rdparty/distribute-0.6.26/setuptools/__init__.py", line 2, in
>
> from setuptools.extension import Extension, Library
> File "build/3rdparty/distribute-0.6.26/setuptools/extension.py", line 5, in
>
> from setuptools.dist import _get_unpatched
> File "build/3rdparty/distribute-0.6.26/setuptools/dist.py", line 6, in
>
> from setuptools.command.install import install
> File "build/3rdparty/distribute-0.6.26/setuptools/command/__init__.py",
> line 8, in
> from setuptools.command import install_scripts
> File
> "build/3rdparty/distribute-0.6.26/setuptools/command/install_scripts.py",
> line 3, in
> from pkg_resources import Distribution, PathMetadata, ensure_directory
> File "build/3rdparty/distribute-0.6.26/pkg_resources.py", line 2731, in
>
> add_activation_listener(lambda dist: dist.activate())
> File "build/3rdparty/distribute-0.6.26/pkg_resources.py", line 704, in
> subscribe
> callback(dist)
> File "build/3rdparty/distribute-0.6.26/pkg_resources.py", line 2731, in
>
> add_activation_listener(lambda dist: dist.activate())
> File "build/3rdparty/distribute-0.6.26/pkg_resources.py", line 2231, in
> activate
> self.insert_on(path)
> File "build/3rdparty/distribute-0.6.26/pkg_resources.py", line 2332, in
> insert_on
> "with distribute. Found one at %s" % str(self.location))
> ValueError: A 0.7-series setuptools cannot be installed with distribute.
> Found one at /usr/lib/python2.7/dist-packages
> Makefile:10277: recipe for target
> '../3rdparty/libprocess/3rdparty/protobuf-2.5.0/python/dist/protobuf-2.5.0-py2.7.egg'
> failed
> make[2]: ***
> [../3rdparty/libprocess/3rdparty/protobuf-2.5.0/python/dist/protobuf-2.5.0-py2.7.egg]
> Error 1
> make[2]: Leaving directory 'build/src'
> Makefile:2805: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory 'build/src'
> Makefile:731: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1169) Update system check (distribute)
[ https://issues.apache.org/jira/browse/MESOS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1169: - Comment: was deleted (was: www.rtat.net) > Update system check (distribute) > > > Key: MESOS-1169 > URL: https://issues.apache.org/jira/browse/MESOS-1169 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.19.0 >Reporter: Timothy St. Clair >Assignee: Timothy St. Clair >Priority: Major > > Clean up distribute detection to follow > https://issues.apache.org/jira/browse/MESOS-1071 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6328) Make initialization of openssl eager
[
https://issues.apache.org/jira/browse/MESOS-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-6328:
-
Comment: was deleted
(was: www.rtat.net)
> Make initialization of openssl eager
>
>
> Key: MESOS-6328
> URL: https://issues.apache.org/jira/browse/MESOS-6328
> Project: Mesos
> Issue Type: Bug
> Components: security
>Reporter: Benjamin Bannier
>Priority: Minor
>
> Currently openssl is initialized lazily since {{openssl::initialize}} is
> called whenever the first ssl socket is created with
> {{LibeventSSLSocketImpl::create}}, while it should be possible to just call
> it in spots where {{process::initialize}} is called.
> This was brought up during https://reviews.apache.org/r/52154/.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1855) Mesos 0.20.1 doesn't compile
[ https://issues.apache.org/jira/browse/MESOS-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1855: - Comment: was deleted (was: www.rtat.net) > Mesos 0.20.1 doesn't compile > > > Key: MESOS-1855 > URL: https://issues.apache.org/jira/browse/MESOS-1855 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.20.1 > Environment: Ubuntu Trusty >Reporter: Diptanu Choudhury >Assignee: Jie Yu >Priority: Major > Fix For: 0.21.0 > > > The compilation of Mesos 0.20.1 fails on Ubuntu Trusty with the following > error - > slave/containerizer/mesos/containerizer.cpp -fPIC -DPIC -o > slave/containerizer/mesos/.libs/libmesos_no_3rdparty_la-containerizer.o > In file included from ./linux/routing/filter/ip.hpp:36:0, > from > ./slave/containerizer/isolators/network/port_mapping.hpp:42, > from slave/containerizer/mesos/containerizer.cpp:44: > ./linux/routing/filter/filter.hpp:29:43: fatal error: > linux/routing/filter/handle.hpp: No such file or directory > #include "linux/routing/filter/handle.hpp" >^ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3161) Document using the gold linker for faster development on linux.
[
https://issues.apache.org/jira/browse/MESOS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-3161:
-
Comment: was deleted
(was: www.rtat.net)
> Document using the gold linker for faster development on linux.
> ---
>
> Key: MESOS-3161
> URL: https://issues.apache.org/jira/browse/MESOS-3161
> Project: Mesos
> Issue Type: Improvement
> Components: build, documentation
>Reporter: Benjamin Mahler
>Priority: Major
> Labels: newbie
>
> The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to
> provide a decent speedup (about ~20%) on a parallel build. From a quick test:
> {noformat: title=timings for make check -j24 GTEST_FILTER="" w/ 24
> hyperthreaded cores}
> gold:
> real 7m18.526s
> user 81m21.213s
> sys 5m17.224s
> default ld:
> real 9m7.908s
> user 85m13.466s
> sys 5m52.199s
> {noformat}
> On CentOS 5 w/ devtoolset-2:
> {noformat}
> sudo /usr/sbin/alternatives --altdir
> /opt/rh/devtoolset-2/root/etc/alternatives --admindir
> /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
> /opt/rh/devtoolset-2/root/usr/bin/ld.gold
> {noformat}
> On Ubuntu:
> {noformat}
> sudo update-alternatives --install /usr/bin/ld ld /usr/bin/gold 1
> {noformat}
> Ideally we could this out on the website, with instructions for each OS.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1290) Unable to find mvn on your path.
[
https://issues.apache.org/jira/browse/MESOS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-1290:
-
Comment: was deleted
(was: www.rtat.net)
> Unable to find mvn on your path.
> -
>
> Key: MESOS-1290
> URL: https://issues.apache.org/jira/browse/MESOS-1290
> Project: Mesos
> Issue Type: Improvement
> Components: build
>Affects Versions: 0.18.1
> Environment: Fedora20
>Reporter: Till Toenshoff
>Assignee: Isabel Jimenez
>Priority: Minor
> Labels: build, configure, maven, mvn
>
> While running configure:
> {{../configure CXX=clang++ CC=clang}}
> the following is displayed:
> {noformat}
> [...]
> checking whether -pthread is sufficient with -shared... yes
> checking for backtrace in -lunwind... no
> checking whether or not we can build with JNI... yes
> checking for mvn... no
> configure: error: Unable to find mvn on your path.
> {noformat}
> While I do know that the culprit is a missing Maven installation, a quick
> google on that exact error message only reveals some Mesos specific links. I
> think it would be great if that error message was a bit more verbose, similar
> to those we display in cases where dependencies like JNI-headers, Zookeeper
> or LevelDB are not found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1926) Enable local cluster to use module loading.
[ https://issues.apache.org/jira/browse/MESOS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1926: - Comment: was deleted (was: www.rtat.net) > Enable local cluster to use module loading. > --- > > Key: MESOS-1926 > URL: https://issues.apache.org/jira/browse/MESOS-1926 > Project: Mesos > Issue Type: Improvement > Components: modules >Reporter: Till Toenshoff >Priority: Major > Labels: integration, mesosphere > > This appears to break down into two issues; > [launch|https://issues.apache.org/jira/browse/MESOS-1927]: Given that > frameworks can launch a local cluster implicitly (for testing purposes), we > need to enable local/launch.cpp to load modules. > [mesos-local|https://issues.apache.org/jira/browse/MESOS-1928]: Enable > loadable modules within the executable via changes in local/main.cpp. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4713) ReviewBot should not fail hard if there are circular dependencies in a review chain
[ https://issues.apache.org/jira/browse/MESOS-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-4713: - Comment: was deleted (was: www.rtat.net) > ReviewBot should not fail hard if there are circular dependencies in a review > chain > --- > > Key: MESOS-4713 > URL: https://issues.apache.org/jira/browse/MESOS-4713 > Project: Mesos > Issue Type: Task > Components: reviewbot >Reporter: Vinod Kone >Assignee: Vinod Kone >Priority: Major > Fix For: 0.28.0 > > > Instead of failing hard, ReviewBot should post an error to the review that a > circular dependency is detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3198) mesos.native could not found
[ https://issues.apache.org/jira/browse/MESOS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3198: - Comment: was deleted (was: www.rtat.net) > mesos.native could not found > > > Key: MESOS-3198 > URL: https://issues.apache.org/jira/browse/MESOS-3198 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.23.0 > Environment: Ubuntu14.04 Mesos0.23.0 >Reporter: pugna >Priority: Major > Labels: build, newbie, python > Attachments: Re mesos.native could not found.msg > > > I deploy apache mesos-0.23 on Ubuntu14.04 This error comes from the last step > "# Run Python framework (Exits after successfully running some tasks.). $ > ./src/examples/python/test-framework 127.0.0.1:5050" > Mesos/src/examples/python/test_framework.py line 25, mesos.native could not > found > Anyone who can help me solve this problem? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3381) Include ZooKeeper in Windows CMake build
[ https://issues.apache.org/jira/browse/MESOS-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3381: - Comment: was deleted (was: www.rtat.net) > Include ZooKeeper in Windows CMake build > > > Key: MESOS-3381 > URL: https://issues.apache.org/jira/browse/MESOS-3381 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Alex Clemmer >Priority: Major > Labels: build, cmake, mesosphere > > Windows agent will require ZK to operate, which means that (at least in the > short term) we have to unbundle the tar'd version and build it locally on > Windows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-978) Building libprocess fails on ubuntu 12.10 w/ clang
[
https://issues.apache.org/jira/browse/MESOS-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-978:
Comment: was deleted
(was: www.rtat.net)
> Building libprocess fails on ubuntu 12.10 w/ clang
> --
>
> Key: MESOS-978
> URL: https://issues.apache.org/jira/browse/MESOS-978
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.18.0
> Environment: ubuntu 12.10 w/ clang
>Reporter: Vinod Kone
>Priority: Major
>
> In file included from src/latch.cpp:3:
> In file included from ./include/process/process.hpp:11:
> In file included from ./include/process/event.hpp:4:
> ./include/process/future.hpp:310:17: error: invalid use of 'this' outside of
> a nonstatic member function
> -> decltype(this->then(std::forward(f), Prefer()))
> ^
> ./include/process/future.hpp:311:3: error: type name requires a specifier or
> qualifier
> {
> ^
> ./include/process/future.hpp:311:3: error: C++ requires a type specifier for
> all declarations
> {
> ^
> ./include/process/future.hpp:309:3: error: 'auto' return without trailing
> return type
> auto then(F&& f) const
> ^
> ./include/process/future.hpp:171:13: error: use of undeclared identifier 't'
> f(t);
> ^
> 0 libLLVM-3.0.so.1 0x2b8df885866f
> 1 libLLVM-3.0.so.1 0x2b8df8858ad9
> 2 libpthread.so.0 0x2b8df9197cb0
> 3 clang0x00d2570a
> clang::CXXUnresolvedConstructExpr::CXXUnresolvedConstructExpr(clang::TypeSourceInfo*,
> clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation) +
> 298
> 4 clang0x00d257a7
> clang::CXXUnresolvedConstructExpr::Create(clang::ASTContext&,
> clang::TypeSourceInfo*, clang::SourceLocation, clang::Expr**, unsigned int,
> clang::SourceLocation) + 103
> 5 clang0x0094f2c6
> clang::Sema::BuildCXXTypeConstructExpr(clang::TypeSourceInfo*,
> clang::SourceLocation, clang::ASTMultiPtr,
> clang::SourceLocation) + 150
> 6 clang0x0094f854
> clang::Sema::ActOnCXXTypeConstructExpr(clang::OpaquePtr,
> clang::SourceLocation, clang::ASTMultiPtr,
> clang::SourceLocation) + 84
> 7 clang0x00815fb2
> clang::Parser::ParseCXXTypeConstructExpression(clang::DeclSpec const&) + 674
> 8 clang0x0080e931
> clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 7361
> 9 clang0x0080f59e
> clang::Parser::ParseCastExpression(bool, bool, bool) + 30
> 10 clang0x0080d7c0
> clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 2896
> 11 clang0x0080f59e
> clang::Parser::ParseCastExpression(bool, bool, bool) + 30
> 12 clang0x0080fe8f
> clang::Parser::ParseAssignmentExpression() + 31
> 13 clang0x0080ff5e
> clang::Parser::ParseExpressionList(llvm::SmallVectorImpl&,
> llvm::SmallVectorImpl&, void
> (clang::Sema::*)(clang::Scope*, clang::Expr*, clang::Expr**, unsigned int),
> clang::Expr*) + 110
> 14 clang0x0081239b
> clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult true>) + 731
> 15 clang0x0080cd3b
> clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 203
> 16 clang0x0080f59e
> clang::Parser::ParseCastExpression(bool, bool, bool) + 30
> 17 clang0x0080fe8f
> clang::Parser::ParseAssignmentExpression() + 31
> 18 clang0x00810c59 clang::Parser::ParseExpression() + 9
> 19 clang0x007c9937
> clang::Parser::ParseReturnStatement(clang::ParsedAttributes&) + 103
> 20 clang0x007cf5c6
> clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector 32u>&, bool) + 486
> 21 clang0x007cca11
> clang::Parser::ParseCompoundStatementBody(bool) + 417
> 22 clang0x007cd6fa
> clang::Parser::ParseFunctionStatementBody(clang::Decl*,
> clang::Parser::ParseScope&) + 138
> 23 clang0x007e98d9
> clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 601
> 24 clang0x007e9609
> clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 121
> 25 clang0x00807dc7
> clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned
> int, clang::Decl*) + 2407
> 26 clang0x00808f2b
> clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
> clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
> const&, clang::AccessSpecifier, bool) + 3275
> 27 clang0x007f78f1
> clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
> clang::Parser::ParsedTemplateInfo const&, clang::Access
[jira] [Issue Comment Deleted] (MESOS-7763) How to implement custom authentication / authorization modules
[ https://issues.apache.org/jira/browse/MESOS-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-7763: - Comment: was deleted (was: www.rtat.net) > How to implement custom authentication / authorization modules > -- > > Key: MESOS-7763 > URL: https://issues.apache.org/jira/browse/MESOS-7763 > Project: Mesos > Issue Type: Documentation > Components: documentation, modules, security >Reporter: Sean Mitch >Priority: Major > Labels: documentation, modules, security > > The documentation about how to implement new modules seems to be kind of > incomplete and/or difficult to understand. The same goes for the given > example. > In the particular case of authentication / authorization module, as it is > right now, I can't understand where to start, what interfaces and/or files > are involved, which parameters are needed... > I think this could be improved by creating a complete step by step guide > explaining how to create a new custom module. A good way of being sure that > it would be clear to everyone, could be to have a practical example starting > with the basic/clean install of Mesos and creating a simple module (the data > could also come from files, or database or somewhere else... that's just > "normal/generic" programming). > This issue from Feb 2016 seems to be more or less about the same: > https://issues.apache.org/jira/browse/MESOS-4631 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5091) Move Containerizer::resources out of containerizer interface
[ https://issues.apache.org/jira/browse/MESOS-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5091: - Comment: was deleted (was: www.rtat.net) > Move Containerizer::resources out of containerizer interface > > > Key: MESOS-5091 > URL: https://issues.apache.org/jira/browse/MESOS-5091 > Project: Mesos > Issue Type: Task > Components: containerization, modules >Reporter: haosdent >Assignee: haosdent >Priority: Major > Labels: container, modularization > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-972) bootstrap script is broken on distributions.
[ https://issues.apache.org/jira/browse/MESOS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-972: Comment: was deleted (was: www.rtat.net) > bootstrap script is broken on distributions. > > > Key: MESOS-972 > URL: https://issues.apache.org/jira/browse/MESOS-972 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.15.0, 0.16.0, 0.17.0 >Reporter: Benjamin Mahler >Priority: Minor > > Looks like we the 'm4' directory in stout is not missing from the > distribution: > $ ./bootstrap > ... > m4/acx_pthread.m4:363: ACX_PTHREAD is expanded from... > configure.ac:87: the top level > autoreconf: configure.ac: adding subdirectory 3rdparty/stout to autoreconf > autoreconf: Entering directory `3rdparty/stout' > aclocal: error: couldn't open directory 'm4': No such file or directory > autoreconf: aclocal failed with exit status: 1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-50) Use of pushd and popd in makefile based on sh (not bash)
[ https://issues.apache.org/jira/browse/MESOS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-50: --- Comment: was deleted (was: www.rtat.net) > Use of pushd and popd in makefile based on sh (not bash) > > > Key: MESOS-50 > URL: https://issues.apache.org/jira/browse/MESOS-50 > Project: Mesos > Issue Type: Bug > Components: build > Environment: Ubuntu Lucid >Reporter: Ed Kohlwey >Assignee: Ed Kohlwey >Priority: Blocker > Attachments: MESOS-50.patch, MESOS-50.patch > > > The mesos build scripts use pushd and popd. These commands are particular to > bash. > For whatever reason OSX and possibly other unixes implement them in sh; > Ubuntu does not (and it probably shouldn't). > The build shell should probably be switched to bash. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-8253) Mesos CI docker rmi conflict
[
https://issues.apache.org/jira/browse/MESOS-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-8253:
-
Comment: was deleted
(was: www.rtat.net)
> Mesos CI docker rmi conflict
>
>
> Key: MESOS-8253
> URL: https://issues.apache.org/jira/browse/MESOS-8253
> Project: Mesos
> Issue Type: Bug
> Components: build, docker
>Reporter: James Peach
>Assignee: Michael Park
>Priority: Major
> Fix For: 1.4.2, 1.5.0
>
>
> We are seeing a lot of docker build jobs failing when they try to clean up
> there docker images:
> {noformat}
> + docker rmi mesos-1511286604-15916
> Error response from daemon: conflict: unable to remove repository reference
> "mesos-1511286604-15916" (must force) - container 1aabf0225a43 is using its
> referenced image 23292073f88f
> Build step 'Execute shell' marked build as failure
> {noformat}
> The full Jenkins log is
> [here|https://builds.apache.org/job/Mesos-Buildbot/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(ubuntu)&&(!ubuntu-us1)&&(!ubuntu-eu2)&&(!qnode3)&&(!H23)/4486/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3900) Enable mesos-reviewbot project on jenkins to use docker
[ https://issues.apache.org/jira/browse/MESOS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3900: - Comment: was deleted (was: www.rtat.net) > Enable mesos-reviewbot project on jenkins to use docker > --- > > Key: MESOS-3900 > URL: https://issues.apache.org/jira/browse/MESOS-3900 > Project: Mesos > Issue Type: Task > Components: build >Reporter: Jojy Varghese >Assignee: Jojy Varghese >Priority: Major > Labels: mesosphere > Fix For: 0.26.0 > > > As a first step to adding capability for building multiple configurations on > reviewbot, we need to change the build scripts to use docker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-2304) Add check for libc++/clang to configure
[
https://issues.apache.org/jira/browse/MESOS-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-2304:
-
Comment: was deleted
(was: www.rtat.net)
> Add check for libc++/clang to configure
> ---
>
> Key: MESOS-2304
> URL: https://issues.apache.org/jira/browse/MESOS-2304
> Project: Mesos
> Issue Type: Task
> Components: build
>Reporter: Dominic Hamon
>Priority: Major
>
> When building on Ubuntu 12.04 LTS with clang, the build fails. This is due to
> a mismatch between libc and clang packages available on Ubuntu.
> We should check for this combination in configure and use libc++ instead, if
> it's available.
> travis-ci build output below:
> {noformat:title=compiler}
> $ export CXX=clang++
> $ export CC=clang
> $ clang --version
> clang version 3.4 (tags/RELEASE_34/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> {noformat}
> appears to be using libc 4.6, which we are supposed to support.
> {noformat:title=build log}
> Making check in .
> make[4]: Entering directory
> `/home/travis/build/apache/mesos/build/3rdparty/libprocess'
> /bin/bash ./libtool --tag=CXX --mode=compile clang++
> -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\"
> -DVERSION=\"0.0.1\" -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_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_LIBCURL=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -I.
> -I../../../3rdparty/libprocess -I../../../3rdparty/libprocess/include
> -I../../../3rdparty/libprocess/3rdparty/stout/include -I3rdparty/boost-1.53.0
> -I3rdparty/libev-4.15 -I3rdparty/picojson-4f93734 -I3rdparty/glog-0.3.3/src
> -I3rdparty/ry-http-parser-1c3624a -I/usr/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -g -O0 -std=c++11 -MT
> libprocess_la-http.lo -MD -MP -MF .deps/libprocess_la-http.Tpo -c -o
> libprocess_la-http.lo `test -f 'src/http.cpp' || echo
> '../../../3rdparty/libprocess/'`src/http.cpp
> libtool: compile: clang++ -DPACKAGE_NAME=\"libprocess\"
> -DPACKAGE_TARNAME=\"libprocess\" -DPACKAGE_VERSION=\"0.0.1\"
> "-DPACKAGE_STRING=\"libprocess 0.0.1\"" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\" -DVERSION=\"0.0.1\"
> -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_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_LIBCURL=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -I.
> -I../../../3rdparty/libprocess -I../../../3rdparty/libprocess/include
> -I../../../3rdparty/libprocess/3rdparty/stout/include -I3rdparty/boost-1.53.0
> -I3rdparty/libev-4.15 -I3rdparty/picojson-4f93734 -I3rdparty/glog-0.3.3/src
> -I3rdparty/ry-http-parser-1c3624a -I/usr/include/subversion-1
> -I/usr/include/apr-1 -I/usr/include/apr-1.0 -g -O0 -std=c++11 -MT
> libprocess_la-http.lo -MD -MP -MF .deps/libprocess_la-http.Tpo -c
> ../../../3rdparty/libprocess/src/http.cpp -fPIC -DPIC -o libprocess_la-http.o
> In file included from ../../../3rdparty/libprocess/src/http.cpp:6:
> In file included from
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/deque:61:
> In file included from
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/bits/stl_algobase.h:65:
> In file included from
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/bits/stl_pair.h:60:
> In file included from
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/bits/move.h:53:
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/type_traits:1191:19:
> error:
> no matching function for call to object of type
> 'std::_Bind
> (*(std::_Placeholder<1>))(const std::basic_string &)>'
> decltype( std::declval<_Functor>()(std::declval<_ArgTypes>()...) )
> ^~~~
> /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/type_traits:1216:7:
> note:
> in instantiation of template class 'std::_Result_of_impl std::_Bind
> (*(std::_Placeholder<1>))(const std::basic_string &)>>' requested
> here
> : _Result_of_impl ^
> ../../../3rdparty/libprocess/include/process/future.hpp:360:78: note: in
> instantiation of template class
>
[jira] [Issue Comment Deleted] (MESOS-7003) Introduce a 'Principal' type
[
https://issues.apache.org/jira/browse/MESOS-7003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7003:
-
Comment: was deleted
(was: www.rtat.net)
> Introduce a 'Principal' type
>
>
> Key: MESOS-7003
> URL: https://issues.apache.org/jira/browse/MESOS-7003
> Project: Mesos
> Issue Type: Task
> Components: executor, security
>Reporter: Greg Mann
>Assignee: Greg Mann
>Priority: Major
> Labels: executor, security
> Fix For: 1.3.0
>
>
> We will introduce a new type to represent the identity of an authenticated
> entity in Mesos: the {{Principal}}. To accomplish this, the following should
> be done:
> * Add the new {{Principal}} type
> * Update the {{AuthenticationResult}} to use {{Principal}}
> * Update all authenticated endpoint handlers to handle this new type
> * Update the default authenticator modules to use the new type
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1679) Update system check (distutils)
[ https://issues.apache.org/jira/browse/MESOS-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1679: - Comment: was deleted (was: www.rtat.net) > Update system check (distutils) > --- > > Key: MESOS-1679 > URL: https://issues.apache.org/jira/browse/MESOS-1679 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.19.0 >Reporter: Thomas Rampelberg >Priority: Major > > Clean up distutils detection to follow > https://issues.apache.org/jira/browse/MESOS-1071 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9100) Windows build failure with CMake (gflags::FlagRegister)
[
https://issues.apache.org/jira/browse/MESOS-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9100:
-
Comment: was deleted
(was: www.rtat.net)
> Windows build failure with CMake (gflags::FlagRegister)
> ---
>
> Key: MESOS-9100
> URL: https://issues.apache.org/jira/browse/MESOS-9100
> Project: Mesos
> Issue Type: Bug
> Components: build, cmake
>Affects Versions: 1.6.0
> Environment:
> *Build environment:*
> Windows 10 (RS3)
> Visual Studio 15.2 2017 Win64 (26430.6 Release)
> Latest Cygwin64 tools (GnuWin32 patch would not patch the sources without
> failing)
>Reporter: Gregory Junker
>Priority: Major
> Labels: build, windows
>
> Building on Windows 10 following the instructions here:
> [http://mesos.apache.org/documentation/latest/windows/]
>
> Getting the following linker error (for many different targets, only one
> shown as an example):
> {noformat}
> "C:\cygwin64\home\gjunker\projects\mesos\build\src\slave\mesos-agent.vcxproj"
> (default target) (1) ->
>
> "C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj"
> (default target) (29) ->
> glog.lib(logging.obj) : error LNK2019: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z) referenced in function "void
> __cdecl fLS::`dynamic initializer for 'o_alsologtoemail''(void)"
> (??__Eo_alsologtoemail@fLS@@YAXXZ)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> glog.lib(vlog_is_on.obj) : error LNK2001: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> glog.lib(utilities.obj) : error LNK2001: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> C:\cygwin64\home\gjunker\projects\mesos\build\src\mesos-executor.exe : fatal
> error LNK1120: 1 unresolved externals
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> {noformat}
> *Build commands (run in "build" subdir of Mesos source ToT in Visual Studio
> Command Prompt):*
> {noformat}
> cmake .. -G "Visual Studio 15 2017 Win64" -T "host=x64" -DENABLE_LIBEVENT=1
> -DPATCHEXE_PATH=C:\\cygwin64\\bin
> cmake --build . --target mesos-agent
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6740) Authorize v1 GET_FLAGS call
[ https://issues.apache.org/jira/browse/MESOS-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-6740: - Comment: was deleted (was: www.rtat.net) > Authorize v1 GET_FLAGS call > --- > > Key: MESOS-6740 > URL: https://issues.apache.org/jira/browse/MESOS-6740 > Project: Mesos > Issue Type: Bug > Components: agent, security >Reporter: Adam B >Assignee: Alexander Rojas >Priority: Major > Labels: security > Fix For: 1.2.0 > > > We already have a VIEW_FLAGS ACL that we use for /flags and the flags part of > /state. Let's add authz to the v1 GET_FLAGS API call (on agent and master) > and reuse that ACL. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1681) Unbundle system check (wheel)
[ https://issues.apache.org/jira/browse/MESOS-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-1681: - Comment: was deleted (was: www.rtat.net) > Unbundle system check (wheel) > - > > Key: MESOS-1681 > URL: https://issues.apache.org/jira/browse/MESOS-1681 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.20.0 >Reporter: Thomas Rampelberg >Priority: Major > > Clean up wheel detection to follow > https://issues.apache.org/jira/browse/MESOS-1071 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-2604) Upgrade minimum required compilers for MESOS
[ https://issues.apache.org/jira/browse/MESOS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-2604: - Comment: was deleted (was: www.rtat.net) > Upgrade minimum required compilers for MESOS > > > Key: MESOS-2604 > URL: https://issues.apache.org/jira/browse/MESOS-2604 > Project: Mesos > Issue Type: Improvement > Components: build >Affects Versions: 0.23.0 >Reporter: Cody Maloney >Assignee: Cody Maloney >Priority: Major > Labels: c++11 > Fix For: 0.23.0 > > > As discussed in the last community meeting we would like to upgrade the > minimum mesos compiler version to GCC 4.8+, Clang 3.5. GCC primarily for > Linux. Clang for OS X, as well as linux for enabling Mesos tooling > improvements > ([clang-format|http://mesos.apache.org/documentation/clang-format/], > clang-tidy among others). > Some documents for reference: > [Compilers by Distribution > Version|https://docs.google.com/spreadsheets/d/1Ji8p3p_1JqUsMxE31mJqqztHf7LDx7mGMXh253azWpU/edit?usp=sharing] > Shows we can get GCC 4.8+ or clang 3.5+ on all supported platforms. > C++11 features supported by each compiler: > [https://gcc.gnu.org/projects/cxx0x.html] > [http://clang.llvm.org/cxx_status.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-137) When building, the version of libtool that get's created in the third_parth/zookeeper directory is the wrong version
[ https://issues.apache.org/jira/browse/MESOS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-137: Comment: was deleted (was: www.rtat.net) > When building, the version of libtool that get's created in the > third_parth/zookeeper directory is the wrong version > > > Key: MESOS-137 > URL: https://issues.apache.org/jira/browse/MESOS-137 > Project: Mesos > Issue Type: Bug > Components: build > Environment: Red Hat (Amazon AMI) >Reporter: Matthew Rathbone >Priority: Minor > Labels: build-failure, zookeeper > > The libtool in the root mesos directory is version: libtool (GNU libtool) > 2.2.10 > The version that gets created in the zookeeper directory is a different > version. This causes building zookeeper to fail (as headers have already been > created using the new version, or something like that). > The solution is to replace third_parth/zookeeper/libtool with ./libtool when > you see the error and run configure/make again (not sure at what point this > occurs). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9100) Windows build failure with CMake (gflags::FlagRegister)
[
https://issues.apache.org/jira/browse/MESOS-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9100:
-
Comment: was deleted
(was: www.rtat.net)
> Windows build failure with CMake (gflags::FlagRegister)
> ---
>
> Key: MESOS-9100
> URL: https://issues.apache.org/jira/browse/MESOS-9100
> Project: Mesos
> Issue Type: Bug
> Components: build, cmake
>Affects Versions: 1.6.0
> Environment:
> *Build environment:*
> Windows 10 (RS3)
> Visual Studio 15.2 2017 Win64 (26430.6 Release)
> Latest Cygwin64 tools (GnuWin32 patch would not patch the sources without
> failing)
>Reporter: Gregory Junker
>Priority: Major
> Labels: build, windows
>
> Building on Windows 10 following the instructions here:
> [http://mesos.apache.org/documentation/latest/windows/]
>
> Getting the following linker error (for many different targets, only one
> shown as an example):
> {noformat}
> "C:\cygwin64\home\gjunker\projects\mesos\build\src\slave\mesos-agent.vcxproj"
> (default target) (1) ->
>
> "C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj"
> (default target) (29) ->
> glog.lib(logging.obj) : error LNK2019: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z) referenced in function "void
> __cdecl fLS::`dynamic initializer for 'o_alsologtoemail''(void)"
> (??__Eo_alsologtoemail@fLS@@YAXXZ)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> glog.lib(vlog_is_on.obj) : error LNK2001: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> glog.lib(utilities.obj) : error LNK2001: unresolved external symbol "public:
> __cdecl gflags::FlagRegisterer::FlagRegisterer(char const *,char const *,char
> const *,char const *,void *,void *)"
> (??0FlagRegisterer@gflags@@QEAA@PEBD000PEAX1@Z)
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> C:\cygwin64\home\gjunker\projects\mesos\build\src\mesos-executor.exe : fatal
> error LNK1120: 1 unresolved externals
> [C:\cygwin64\home\gjunker\projects\mesos\build\src\launcher\mesos-executor.vcxproj]
> {noformat}
> *Build commands (run in "build" subdir of Mesos source ToT in Visual Studio
> Command Prompt):*
> {noformat}
> cmake .. -G "Visual Studio 15 2017 Win64" -T "host=x64" -DENABLE_LIBEVENT=1
> -DPATCHEXE_PATH=C:\\cygwin64\\bin
> cmake --build . --target mesos-agent
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9606) Reviewbot should only rebuild master if there are actually reviews to verify
[
https://issues.apache.org/jira/browse/MESOS-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-9606:
-
Comment: was deleted
(was: www.rtat.net)
> Reviewbot should only rebuild master if there are actually reviews to verify
>
>
> Key: MESOS-9606
> URL: https://issues.apache.org/jira/browse/MESOS-9606
> Project: Mesos
> Issue Type: Improvement
> Components: reviewbot
>Reporter: Benjamin Bannier
>Priority: Major
> Labels: integration
>
> Currently the Jenkins reviewbot setup first verifies that the {{master}}
> branch builds, and then invokes {{support/verify_reviews.py}} to validate
> reviews. This means that even if no reviews to build the job still takes
> roughly 40min just to verify the {{master}} branch.
> Instead the job should only validate {{master}} if there are actually reviews
> to validate. This could e.g., be accomplished by providing a "query flag" for
> {{support/verify_reviews.py}} which can return which reviews need validation
> and branching on that in the Jenkins shell script, or alternatively moving
> the building of {{master}} into {{support/verify_reviews.py}} (which might
> unlock other improvements like sharing a ccache between {{master}} build and
> builds of reviews).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-4901) Build fails on some systems due to unportable use of time.h
[ https://issues.apache.org/jira/browse/MESOS-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-4901: - Comment: was deleted (was: www.rtat.net) > Build fails on some systems due to unportable use of time.h > --- > > Key: MESOS-4901 > URL: https://issues.apache.org/jira/browse/MESOS-4901 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.25.1 >Reporter: Jim Carroll >Assignee: Neil Conway >Priority: Major > Fix For: 1.0.0 > > > The 3rdparty library header file: > 3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp > uses #include but then assumes "struct timevar" is defined. "struct > timevar" is defined in not in . This works on most > systems but not on all. > Notably, it doesn't work on Alpine. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (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
]
Gavin updated MESOS-3216:
-
Comment: was deleted
(was: www.rtat.net)
> 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
>Priority: Major
>
> 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/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/
[jira] [Issue Comment Deleted] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` not idempotent
[
https://issues.apache.org/jira/browse/MESOS-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7262:
-
Comment: was deleted
(was: www.rtat.net)
> Symlink mesos-agent to mesos-slave on `make install` not idempotent
> ---
>
> Key: MESOS-7262
> URL: https://issues.apache.org/jira/browse/MESOS-7262
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.2.0
>Reporter: pawan
>Priority: Major
>
> I issued a make install twice after building Mesos from source, but its
> failing with the following error:
> {code}
> ln -s mesos-agent mesos-slave
> ln: failed to create symbolic link ‘mesos-slave’: File exists
> {code}
> I believe `make install` has to be idempotent. It looks like LN_S in Makefile
> aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-1559) Allow jenkins build machine to dump stack traces of all threads when timeout
[
https://issues.apache.org/jira/browse/MESOS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-1559:
-
Comment: was deleted
(was: www.rtat.net)
> Allow jenkins build machine to dump stack traces of all threads when timeout
>
>
> Key: MESOS-1559
> URL: https://issues.apache.org/jira/browse/MESOS-1559
> Project: Mesos
> Issue Type: Improvement
> Components: build
>Reporter: Jie Yu
>Assignee: Yan Xu
>Priority: Minor
> Fix For: 0.20.0
>
>
> Many of the time, when jenkins build times out, we know that some test
> freezes at some place. However, most of the time, it's very hard to reproduce
> the deadlock on dev machines.
> I would be cool if we can dump the stack traces of all threads when jenkins
> build times out. Some command like the following:
> {noformat}
> echo thread apply all bt > tmp; gdb attach `pgrep lt-mesos-tests` < tmp
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3526) Transition Windows from libevent to libev
[ https://issues.apache.org/jira/browse/MESOS-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3526: - Comment: was deleted (was: www.rtat.net) > Transition Windows from libevent to libev > - > > Key: MESOS-3526 > URL: https://issues.apache.org/jira/browse/MESOS-3526 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Andrew Schwartzmeyer >Assignee: Andrew Schwartzmeyer >Priority: Major > Labels: build, cmake, mesosphere, windows > > Right now we have to use libevent to compile Mesos on Windows because libev > does not have a clean standalone build available on Windows. (We also use a > beta version of libevent because it's easier to compile.) > But, this changes the behavior of libprocess significantly. So, we need to > think about transitioning to libev after MVP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5129) Supporting Container Images in Mesos Containerizer doesn't work
[
https://issues.apache.org/jira/browse/MESOS-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-5129:
-
Comment: was deleted
(was: www.rtat.net)
> Supporting Container Images in Mesos Containerizer doesn't work
> ---
>
> Key: MESOS-5129
> URL: https://issues.apache.org/jira/browse/MESOS-5129
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 1.0.0
>Reporter: wangqun
>Priority: Major
>
> lsHi
> I try to test the feature of Supporting Container Images in Mesos
> Containerizer according to
> https://github.com/apache/mesos/blob/master/docs/container-image.md#test-it-out.
> But it doesn't work.
>I use the mesos 0.29 version.
> The following is my step:
> 1) sudo bin/mesos-master.sh --log_dir=/var/log/mesos --ip=9.5.124.139
> --work_dir=/tmp/mesos/master
> 2) sudo bin/mesos-slave.sh --master=9.5.124.139:5050 --ip=9.5.124.139
> --hostname=mesos --isolation=docker/runtime,filesystem/linux
> --work_dir=/tmp/mesos/slave --log_dir=/var/log/mesos --image_providers=docker
> --executor_environment_variables="{}"
> 3)sudo src/mesos-execute --master=9.5.124.139:5050 --name=test
> --docker_image=library/redis --shell=false
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> W0406 03:33:05.730432 5886 scheduler.cpp:157]
> **
> Scheduler driver bound to loopback interface! Cannot communicate with remote
> master(s). You might want to set 'LIBPROCESS_IP' environment variable to use
> a routable IP address.
> **
> I0406 03:33:05.730623 5886 scheduler.cpp:172] Version: 0.29.0
> Subscribed with ID '79b6ed58-46a9-4760-a589-a28061f4f1e9-
> task test submitted to agent 7184bc3a-243c-4ca7-8897-c98e81836ed6-S1
> Received status update TASK_RUNNING for task test
> 4) sudo vim lt-mesos-slave.mesos.root.log.ERROR
> Command 'hadoop version 2>&1' failed; this is the output:
> sh: 1: hadoop: not found
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7708) Some of the headers/functions defined in `src/common` should probably be in `include`
[
https://issues.apache.org/jira/browse/MESOS-7708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7708:
-
Comment: was deleted
(was: www.rtat.net)
> Some of the headers/functions defined in `src/common` should probably be in
> `include`
> -
>
> Key: MESOS-7708
> URL: https://issues.apache.org/jira/browse/MESOS-7708
> Project: Mesos
> Issue Type: Improvement
> Components: modules
>Reporter: Alexander Rojas
>Priority: Minor
> Labels: mesosphere
>
> Some of the functions/methods defined in {{src/common/}} are useful enough to
> be part of {{include/mesos/common}}. In particular, functions declared in
> {{protobuf_utils.hpp}} are helpful enough to module writers that would be
> better located in the public API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9337) Hook manager implementation is missing mutex acquisition in several places.
[ https://issues.apache.org/jira/browse/MESOS-9337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9337: - Comment: was deleted (was: www.rtat.net) > Hook manager implementation is missing mutex acquisition in several places. > --- > > Key: MESOS-9337 > URL: https://issues.apache.org/jira/browse/MESOS-9337 > Project: Mesos > Issue Type: Bug > Components: modules >Reporter: Benjamin Mahler >Priority: Major > > The hook manager uses a mutex to protect availableHooks from writing during > read (probably this should be a read/write mutex). > However, this mutex is not acquired in many of the reads. For example: > (mutex acquired) > https://github.com/apache/mesos/blob/1.7.0/src/hook/manager.cpp#L108-L138 > (mutex not acquired!) > https://github.com/apache/mesos/blob/1.7.0/src/hook/manager.cpp#L141-L150 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7999) Add and document ability to expose new /monitor modules on agents
[
https://issues.apache.org/jira/browse/MESOS-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7999:
-
Comment: was deleted
(was: www.rtat.net)
> Add and document ability to expose new /monitor modules on agents
> -
>
> Key: MESOS-7999
> URL: https://issues.apache.org/jira/browse/MESOS-7999
> Project: Mesos
> Issue Type: Wish
> Components: agent, json api, modules, statistics
>Reporter: Charles R Allen
>Priority: Major
>
> When looking at how to collect data about the cluster, the best way to
> support functionality similar to Kubernetes DaemonSets is not completely
> clear.
> One key use case fore DaemonSets is a monitor for system metrics. This ask is
> that agents are able to have a module which either exposes new endpoints in
> {{/monitor}} or allows pluggable entries to be added to
> {{/monitor/statistics}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5164) Add authorization to agent's /monitor/statistics endpoint.
[ https://issues.apache.org/jira/browse/MESOS-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5164: - Comment: was deleted (was: www.rtat.net) > Add authorization to agent's /monitor/statistics endpoint. > -- > > Key: MESOS-5164 > URL: https://issues.apache.org/jira/browse/MESOS-5164 > Project: Mesos > Issue Type: Task > Components: agent, security >Reporter: Adam B >Assignee: Benjamin Bannier >Priority: Major > Labels: authorization, mesosphere, security > Fix For: 1.0.0 > > > Operators may want to enforce that only specific authorized users be able to > view per-executor resource usage statistics. For 0.29 MVP, we can make this > coarse-grained, and assume that only the operator or a operator-privileged > monitoring service will be accessing the endpoint. > For a future release, we can consider fine-grained authz that filters > statistics like we plan to do for /tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-9406) Allow for optionally unbundled leveldb from CMake builds.
[ https://issues.apache.org/jira/browse/MESOS-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-9406: - Comment: was deleted (was: www.rtat.net) > Allow for optionally unbundled leveldb from CMake builds. > - > > Key: MESOS-9406 > URL: https://issues.apache.org/jira/browse/MESOS-9406 > Project: Mesos > Issue Type: Improvement > Components: build, cmake >Affects Versions: 1.8.0 >Reporter: Till Toenshoff >Assignee: Till Toenshoff >Priority: Minor > Labels: cmake, unbundled-dependencies > Fix For: 1.8.0 > > > Following the example of unbundled libevent and libarchive, we should allow > for unbundled leveldb if the user wishes so. > For leveldb, this task is not as trivial as one would hope due to the fact > that we link leveldb statically. This forces us to satisfy leveldb's strong > dependencies against gpertools (tcmalloc) as well as snappy. > Alternatively, we would resort into linking leveldb dynamically, solving > these issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-3453) Add patch file to silence deprecation warnings when we compile protobufs on Windows
[ https://issues.apache.org/jira/browse/MESOS-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-3453: - Comment: was deleted (was: www.rtat.net) > Add patch file to silence deprecation warnings when we compile protobufs on > Windows > --- > > Key: MESOS-3453 > URL: https://issues.apache.org/jira/browse/MESOS-3453 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Andrew Schwartzmeyer >Priority: Major > Labels: cmake, mesosphere, microsoft, windows-mvp > > Right now when you compile Protobuf v2.5.0, it gives you deprecation warnings > because stdext was removed. You can silence these, but it will require either > submitting a PR to the project or adding a patchfile to be applied to the > repot when you untar it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-7014) Add implicit executor authorization to local authorizer
[
https://issues.apache.org/jira/browse/MESOS-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-7014:
-
Comment: was deleted
(was: www.rtat.net)
> Add implicit executor authorization to local authorizer
> ---
>
> Key: MESOS-7014
> URL: https://issues.apache.org/jira/browse/MESOS-7014
> Project: Mesos
> Issue Type: Task
> Components: security
>Reporter: Greg Mann
>Assignee: Greg Mann
>Priority: Major
> Labels: authorization, executor, mesosphere, security
> Fix For: 1.3.0
>
>
> The local authorizer should be updated to perform implicit authorization of
> executor actions. When executors authenticate using a default executor
> secret, the authorizer will receive an authorization {{Subject}} which
> contains claims, but no principal. In this case, implicit authorization
> should be performed. Implicit authorization rules should enforce that an
> executor can perform actions on itself; i.e., subscribe as itself, send
> messages as itself, launch nested containers within itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-6642) Provide a slave hook for adding volumes to a task's container.
[ https://issues.apache.org/jira/browse/MESOS-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-6642: - Comment: was deleted (was: www.rtat.net) > Provide a slave hook for adding volumes to a task's container. > --- > > Key: MESOS-6642 > URL: https://issues.apache.org/jira/browse/MESOS-6642 > Project: Mesos > Issue Type: Improvement > Components: modules >Reporter: Till Toenshoff >Priority: Major > Labels: hooks > > We should allow a hook to provide additional volumes before launching a > container. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (MESOS-5708) Add authz to /files/debug
[ https://issues.apache.org/jira/browse/MESOS-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin updated MESOS-5708: - Comment: was deleted (was: www.rtat.net) > Add authz to /files/debug > - > > Key: MESOS-5708 > URL: https://issues.apache.org/jira/browse/MESOS-5708 > Project: Mesos > Issue Type: Task > Components: security >Reporter: Adam B >Assignee: Abhishek Dasgupta >Priority: Minor > Labels: mesosphere, security > Fix For: 1.0.0 > > > The /files/debug endpoint exposes the attached master/agent log paths and > every attached sandbox path, which includes the frameworkId and executorId. > Even if sandboxes are protected, we still don't want to expose this > information to unauthorized users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
