[jira] [Created] (MESOS-1729) LogZooKeeperTest.WriteRead fails on OSX
Till Toenshoff created MESOS-1729:
-
Summary: LogZooKeeperTest.WriteRead fails on OSX
Key: MESOS-1729
URL: https://issues.apache.org/jira/browse/MESOS-1729
Project: Mesos
Issue Type: Bug
Components: build, test
Affects Versions: 0.21.0
Environment: OSX 10.9.4, clang 3.4
Reporter: Till Toenshoff
The following is reported and 100% reproducible when running {{make check}} on
my OSX box.
{noformat}
[ RUN ] LogZooKeeperTest.WriteRead
W0821 12:36:35.715975 1914815248 glog.hpp:52] RAW: Received signal SIGPIPE;
escalating to SIGABRT
*** Aborted at 1408617395 (unix time) try date -d @1408617395 if you are
using GNU date ***
PC: @ 0x7fff8523b292 __kill
*** SIGABRT (@0x7fff8523b292) received by PID 90142 (TID 0x7fff7221c310) stack
trace: ***
@ 0x7fff8a2905aa _sigtramp
@ 0x7fff7276f338 usual
@0x10e35737d os::Bsd::chained_handler()
@0x10e35b166 JVM_handle_bsd_signal
@ 0x7fff8a2905aa _sigtramp
@0x0 (unknown)
@0x10bbec97b process::ProcessManager::wait()
@0x10bbee96b process::wait()
@0x10baf062a mesos::internal::log::Log::~Log()
@0x10a63857a LogZooKeeperTest_WriteRead_Test::TestBody()
@0x10a9bff8c
testing::internal::HandleExceptionsInMethodIfSupported()
@0x10a9ab90a testing::Test::Run()
@0x10a9ac592 testing::TestInfo::Run()
@0x10a9acbd0 testing::TestCase::Run()
@0x10a9b2425 testing::internal::UnitTestImpl::RunAllTests()
@0x10a9c0754
testing::internal::HandleExceptionsInMethodIfSupported()
@0x10a9b2159 testing::UnitTest::Run()
@0x10a66ea33 main
@ 0x7fff8c1c65fd start
@0x1 (unknown)
make[3]: *** [check-local] Abort trap: 6
make[2]: *** [check-am] Error 2
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MESOS-1729) LogZooKeeperTest.WriteRead fails on OSX
[
https://issues.apache.org/jira/browse/MESOS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105987#comment-14105987
]
Till Toenshoff commented on MESOS-1729:
---
I am wildly guessing here, without proper testing...
Could we possibly have hit an upstream issue in Zookeeper due to their usage of
MSG_NOSIGNAL, which isn't functional on OSX (see [this lesson
learned|https://issues.apache.org/jira/browse/MESOS-912?focusedCommentId=13899069page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13899069]
in our libprocess past)?
LogZooKeeperTest.WriteRead fails on OSX
---
Key: MESOS-1729
URL: https://issues.apache.org/jira/browse/MESOS-1729
Project: Mesos
Issue Type: Bug
Components: build, test
Affects Versions: 0.21.0
Environment: OSX 10.9.4, clang 3.4
Reporter: Till Toenshoff
Labels: test
The following is reported and 100% reproducible when running {{make check}}
on my OSX box.
{noformat}
[ RUN ] LogZooKeeperTest.WriteRead
I0821 21:18:34.960811 2078368528 jvm.cpp:572] Looking up method
init(Ljava/lang/String;)V
I0821 21:18:34.960934 2078368528 jvm.cpp:572] Looking up method
deleteOnExit()V
I0821 21:18:34.961335 2078368528 jvm.cpp:572] Looking up method
init(Ljava/io/File;Ljava/io/File;)V
log4j:WARN No appenders could be found for logger
(org.apache.zookeeper.server.persistence.FileTxnSnapLog).
log4j:WARN Please initialize the log4j system properly.
I0821 21:18:35.004449 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.005053 2078368528 jvm.cpp:572] Looking up method
init(Lorg/apache/zookeeper/server/persistence/FileTxnSnapLog;Lorg/apache/zookeeper/server/ZooKeeperServer$DataTreeBuilder;)V
I0821 21:18:35.025753 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.032670 2078368528 jvm.cpp:572] Looking up method init(I)V
I0821 21:18:35.032873 2078368528 jvm.cpp:572] Looking up method
configure(Ljava/net/InetSocketAddress;I)V
I0821 21:18:35.038020 2078368528 jvm.cpp:572] Looking up method
startup(Lorg/apache/zookeeper/server/ZooKeeperServer;)V
I0821 21:18:35.093870 2078368528 jvm.cpp:572] Looking up method
getClientPort()I
I0821 21:18:35.093925 2078368528 zookeeper_test_server.cpp:158] Started
ZooKeeperTestServer on port 52772
I0821 21:18:35.094081 2078368528 log_tests.cpp:1945] Using temporary
directory '/tmp/LogZooKeeperTest_WriteRead_F8UzYv'
I0821 21:18:35.095954 2078368528 leveldb.cpp:176] Opened db in 1815us
I0821 21:18:35.096392 2078368528 leveldb.cpp:183] Compacted db in 428us
I0821 21:18:35.096420 2078368528 leveldb.cpp:198] Created db iterator in 7us
I0821 21:18:35.096432 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.096442 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 8us
I0821 21:18:35.096462 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.097043 107220992 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 184us
I0821 21:18:35.097075 107220992 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.099768 2078368528 leveldb.cpp:176] Opened db in 1673us
I0821 21:18:35.100049 2078368528 leveldb.cpp:183] Compacted db in 270us
I0821 21:18:35.100070 2078368528 leveldb.cpp:198] Created db iterator in 6us
I0821 21:18:35.100080 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 5us
I0821 21:18:35.100088 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 5us
I0821 21:18:35.100097 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.100411 108294144 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 159us
I0821 21:18:35.100435 108294144 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.101984 2078368528 leveldb.cpp:176] Opened db in 1224us
I0821 21:18:35.102934 2078368528 leveldb.cpp:183] Compacted db in 942us
I0821 21:18:35.102958 2078368528 leveldb.cpp:198] Created db iterator in 8us
I0821 21:18:35.102972 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.102984 2078368528 leveldb.cpp:273] Iterated through 1 keys in
the db in 9us
I0821 21:18:35.102994 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@712: Client
environment:zookeeper.version=zookeeper C client 3.4.5
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@716: Client
environment:host.name=lobomacpro2.fritz.box
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@723: Client
environment:os.name=Darwin
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@724: Client
[jira] [Commented] (MESOS-1729) LogZooKeeperTest.WriteRead fails on OSX
[
https://issues.apache.org/jira/browse/MESOS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106524#comment-14106524
]
Till Toenshoff commented on MESOS-1729:
---
[~jessicahartog] interesting. Are you building using the bundled Zookeeper
version?
LogZooKeeperTest.WriteRead fails on OSX
---
Key: MESOS-1729
URL: https://issues.apache.org/jira/browse/MESOS-1729
Project: Mesos
Issue Type: Bug
Components: build, test
Affects Versions: 0.21.0
Environment: OSX 10.9.4, clang 3.4
Reporter: Till Toenshoff
Labels: test
The following is reported and 100% reproducible when running {{make check}}
on my OSX box.
{noformat}
[ RUN ] LogZooKeeperTest.WriteRead
I0821 21:18:34.960811 2078368528 jvm.cpp:572] Looking up method
init(Ljava/lang/String;)V
I0821 21:18:34.960934 2078368528 jvm.cpp:572] Looking up method
deleteOnExit()V
I0821 21:18:34.961335 2078368528 jvm.cpp:572] Looking up method
init(Ljava/io/File;Ljava/io/File;)V
log4j:WARN No appenders could be found for logger
(org.apache.zookeeper.server.persistence.FileTxnSnapLog).
log4j:WARN Please initialize the log4j system properly.
I0821 21:18:35.004449 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.005053 2078368528 jvm.cpp:572] Looking up method
init(Lorg/apache/zookeeper/server/persistence/FileTxnSnapLog;Lorg/apache/zookeeper/server/ZooKeeperServer$DataTreeBuilder;)V
I0821 21:18:35.025753 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.032670 2078368528 jvm.cpp:572] Looking up method init(I)V
I0821 21:18:35.032873 2078368528 jvm.cpp:572] Looking up method
configure(Ljava/net/InetSocketAddress;I)V
I0821 21:18:35.038020 2078368528 jvm.cpp:572] Looking up method
startup(Lorg/apache/zookeeper/server/ZooKeeperServer;)V
I0821 21:18:35.093870 2078368528 jvm.cpp:572] Looking up method
getClientPort()I
I0821 21:18:35.093925 2078368528 zookeeper_test_server.cpp:158] Started
ZooKeeperTestServer on port 52772
I0821 21:18:35.094081 2078368528 log_tests.cpp:1945] Using temporary
directory '/tmp/LogZooKeeperTest_WriteRead_F8UzYv'
I0821 21:18:35.095954 2078368528 leveldb.cpp:176] Opened db in 1815us
I0821 21:18:35.096392 2078368528 leveldb.cpp:183] Compacted db in 428us
I0821 21:18:35.096420 2078368528 leveldb.cpp:198] Created db iterator in 7us
I0821 21:18:35.096432 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.096442 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 8us
I0821 21:18:35.096462 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.097043 107220992 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 184us
I0821 21:18:35.097075 107220992 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.099768 2078368528 leveldb.cpp:176] Opened db in 1673us
I0821 21:18:35.100049 2078368528 leveldb.cpp:183] Compacted db in 270us
I0821 21:18:35.100070 2078368528 leveldb.cpp:198] Created db iterator in 6us
I0821 21:18:35.100080 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 5us
I0821 21:18:35.100088 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 5us
I0821 21:18:35.100097 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.100411 108294144 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 159us
I0821 21:18:35.100435 108294144 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.101984 2078368528 leveldb.cpp:176] Opened db in 1224us
I0821 21:18:35.102934 2078368528 leveldb.cpp:183] Compacted db in 942us
I0821 21:18:35.102958 2078368528 leveldb.cpp:198] Created db iterator in 8us
I0821 21:18:35.102972 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.102984 2078368528 leveldb.cpp:273] Iterated through 1 keys in
the db in 9us
I0821 21:18:35.102994 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@712: Client
environment:zookeeper.version=zookeeper C client 3.4.5
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@716: Client
environment:host.name=lobomacpro2.fritz.box
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@723: Client
environment:os.name=Darwin
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@724: Client
environment:os.arch=13.3.0
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@725: Client
environment:os.version=Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT
2014; root:xnu-2422.110.17~1/RELEASE_X86_64
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@733: Client
[jira] [Commented] (MESOS-1729) LogZooKeeperTest.WriteRead fails on OSX
[
https://issues.apache.org/jira/browse/MESOS-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14107205#comment-14107205
]
Till Toenshoff commented on MESOS-1729:
---
1.7.0_51 on my OSX box.
LogZooKeeperTest.WriteRead fails on OSX
---
Key: MESOS-1729
URL: https://issues.apache.org/jira/browse/MESOS-1729
Project: Mesos
Issue Type: Bug
Components: build, test
Affects Versions: 0.21.0
Environment: OSX 10.9.4, clang 3.4
Reporter: Till Toenshoff
Labels: test
The following is reported and 100% reproducible when running {{make check}}
on my OSX box.
{noformat}
[ RUN ] LogZooKeeperTest.WriteRead
I0821 21:18:34.960811 2078368528 jvm.cpp:572] Looking up method
init(Ljava/lang/String;)V
I0821 21:18:34.960934 2078368528 jvm.cpp:572] Looking up method
deleteOnExit()V
I0821 21:18:34.961335 2078368528 jvm.cpp:572] Looking up method
init(Ljava/io/File;Ljava/io/File;)V
log4j:WARN No appenders could be found for logger
(org.apache.zookeeper.server.persistence.FileTxnSnapLog).
log4j:WARN Please initialize the log4j system properly.
I0821 21:18:35.004449 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.005053 2078368528 jvm.cpp:572] Looking up method
init(Lorg/apache/zookeeper/server/persistence/FileTxnSnapLog;Lorg/apache/zookeeper/server/ZooKeeperServer$DataTreeBuilder;)V
I0821 21:18:35.025753 2078368528 jvm.cpp:572] Looking up method init()V
I0821 21:18:35.032670 2078368528 jvm.cpp:572] Looking up method init(I)V
I0821 21:18:35.032873 2078368528 jvm.cpp:572] Looking up method
configure(Ljava/net/InetSocketAddress;I)V
I0821 21:18:35.038020 2078368528 jvm.cpp:572] Looking up method
startup(Lorg/apache/zookeeper/server/ZooKeeperServer;)V
I0821 21:18:35.093870 2078368528 jvm.cpp:572] Looking up method
getClientPort()I
I0821 21:18:35.093925 2078368528 zookeeper_test_server.cpp:158] Started
ZooKeeperTestServer on port 52772
I0821 21:18:35.094081 2078368528 log_tests.cpp:1945] Using temporary
directory '/tmp/LogZooKeeperTest_WriteRead_F8UzYv'
I0821 21:18:35.095954 2078368528 leveldb.cpp:176] Opened db in 1815us
I0821 21:18:35.096392 2078368528 leveldb.cpp:183] Compacted db in 428us
I0821 21:18:35.096420 2078368528 leveldb.cpp:198] Created db iterator in 7us
I0821 21:18:35.096432 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.096442 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 8us
I0821 21:18:35.096462 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.097043 107220992 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 184us
I0821 21:18:35.097075 107220992 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.099768 2078368528 leveldb.cpp:176] Opened db in 1673us
I0821 21:18:35.100049 2078368528 leveldb.cpp:183] Compacted db in 270us
I0821 21:18:35.100070 2078368528 leveldb.cpp:198] Created db iterator in 6us
I0821 21:18:35.100080 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 5us
I0821 21:18:35.100088 2078368528 leveldb.cpp:273] Iterated through 0 keys in
the db in 5us
I0821 21:18:35.100097 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0821 21:18:35.100411 108294144 leveldb.cpp:306] Persisting metadata (8
bytes) to leveldb took 159us
I0821 21:18:35.100435 108294144 replica.cpp:320] Persisted replica status to
VOTING
I0821 21:18:35.101984 2078368528 leveldb.cpp:176] Opened db in 1224us
I0821 21:18:35.102934 2078368528 leveldb.cpp:183] Compacted db in 942us
I0821 21:18:35.102958 2078368528 leveldb.cpp:198] Created db iterator in 8us
I0821 21:18:35.102972 2078368528 leveldb.cpp:204] Seeked to beginning of db
in 8us
I0821 21:18:35.102984 2078368528 leveldb.cpp:273] Iterated through 1 keys in
the db in 9us
I0821 21:18:35.102994 2078368528 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@712: Client
environment:zookeeper.version=zookeeper C client 3.4.5
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@716: Client
environment:host.name=lobomacpro2.fritz.box
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@723: Client
environment:os.name=Darwin
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@724: Client
environment:os.arch=13.3.0
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@725: Client
environment:os.version=Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT
2014; root:xnu-2422.110.17~1/RELEASE_X86_64
2014-08-21 21:18:35,103:6420(0x106641000):ZOO_INFO@log_env@733: Client
environment:user.name=till
2014-08-21
[jira] [Commented] (MESOS-1571) Signal escalation timeout is not configurable
[ https://issues.apache.org/jira/browse/MESOS-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14114119#comment-14114119 ] Till Toenshoff commented on MESOS-1571: --- [~nnielsen] Aye! Signal escalation timeout is not configurable - Key: MESOS-1571 URL: https://issues.apache.org/jira/browse/MESOS-1571 Project: Mesos Issue Type: Bug Reporter: Niklas Quarfot Nielsen Assignee: Alexander Rukletsov Even though the executor shutdown grace period is set to a larger interval, the signal escalation timeout will still be 3 seconds. It should either be configurable or dependent on EXECUTOR_SHUTDOWN_GRACE_PERIOD. Thoughts? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1750) ImportError in containerizer_pb2.py
Till Toenshoff created MESOS-1750:
-
Summary: ImportError in containerizer_pb2.py
Key: MESOS-1750
URL: https://issues.apache.org/jira/browse/MESOS-1750
Project: Mesos
Issue Type: Bug
Components: python api
Reporter: Till Toenshoff
It appears as if the split of the Python egg (native/interface/protocol) has
introduced a new issue.
Whenever I am trying to use {{from mesos.interface import containerizer_pb2}},
I am receiving an {{ImportError: No module named mesos_pb2}}.
For replicating this issue, try running
{{build/src/examples/python/test-containerizer}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1750) ImportError in containerizer_pb2.py
[
https://issues.apache.org/jira/browse/MESOS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116911#comment-14116911
]
Till Toenshoff commented on MESOS-1750:
---
{{containerizer.proto}} imports from {{mesos/mesos.proto}}, so the resulting
python code in {{containerizer_pb2.py}} tries to import from
{{mesos.mesos_pb2}} where it should actually import from {{mesos_pb2}}.
It seems as if the translation of the original structure into the flat
interface structure is prone to cause issues with proto's that import from
other mesos proto's while qualifying their relative path.
ImportError in containerizer_pb2.py
---
Key: MESOS-1750
URL: https://issues.apache.org/jira/browse/MESOS-1750
Project: Mesos
Issue Type: Bug
Components: python api
Reporter: Till Toenshoff
Labels: mesos.interface, python-egg
It appears as if the split of the Python egg (native/interface/protocol) has
introduced a new issue.
Whenever I am trying to use {{from mesos.interface import
containerizer_pb2}}, I am receiving an {{ImportError: No module named
mesos_pb2}}.
For replicating this issue, try running
{{build/src/examples/python/test-containerizer}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1007) Python framework unable to parse framework messages
[ https://issues.apache.org/jira/browse/MESOS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117567#comment-14117567 ] Till Toenshoff commented on MESOS-1007: --- I am guessing that this specific issue has magically disappeared and we could close this ticket. [~vinodkone] agree? Python framework unable to parse framework messages --- Key: MESOS-1007 URL: https://issues.apache.org/jira/browse/MESOS-1007 Project: Mesos Issue Type: Bug Environment: Fedora 20. Cxx11 Reporter: Vinod Kone [ RUN ] ExamplesTest.PythonFramework Using temporary directory '/tmp/ExamplesTest_PythonFramework_bk0KRb' WARNING: Logging before InitGoogleLogging() is written to STDERR I0213 22:15:39.954318 17373 process.cpp:1591] libprocess is initialized on 192.168.122.164:47130 for 8 cpus I0213 22:15:39.955761 17373 logging.cpp:140] Logging to STDERR I0213 22:15:39.959444 17373 master.cpp:240] Master ID: 2014-02-13-22:15:39-2759502016-47130-17373 Hostname: fedora-20 I0213 22:15:39.960225 17383 master.cpp:322] Master started on 192.168.122.164:47130 I0213 22:15:39.960244 17383 master.cpp:325] Master only allowing authenticated frameworks to register! I0213 22:15:39.961699 17387 master.cpp:86] No whitelist given. Advertising offers for all slaves I0213 22:15:39.962286 17382 hierarchical_allocator_process.hpp:302] Initializing hierarchical allocator process with master : master@192.168.122.164:47130 I0213 22:15:39.963912 17373 containerizer.cpp:180] Using isolation: posix/cpu,posix/mem I0213 22:15:39.965071 17373 containerizer.cpp:180] Using isolation: posix/cpu,posix/mem I0213 22:15:39.965754 17384 slave.cpp:112] Slave started on 1)@192.168.122.164:47130 I0213 22:15:39.966032 17387 master.cpp:760] The newly elected leader is master@192.168.122.164:47130 with id 2014-02-13-22:15:39-2759502016-47130-17373 I0213 22:15:39.966341 17387 master.cpp:770] Elected as the leading master! I0213 22:15:39.966227 17384 slave.cpp:122] Slave resources: cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] I0213 22:15:39.967811 17384 slave.cpp:150] Slave hostname: fedora-20 I0213 22:15:39.967828 17384 slave.cpp:151] Slave checkpoint: true I0213 22:15:39.968070 17384 state.cpp:33] Recovering state from '/tmp/mesos-KG9dIs/0/meta' I0213 22:15:39.968147 17384 status_update_manager.cpp:188] Recovering status update manager I0213 22:15:39.968200 17384 mesos_containerizer.cpp:137] Recovering containerizer I0213 22:15:39.969071 17384 slave.cpp:2670] Finished recovery I0213 22:15:39.969290 17384 slave.cpp:397] New master detected at master@192.168.122.164:47130 I0213 22:15:39.970041 17384 slave.cpp:422] Detecting new master I0213 22:15:39.970067 17384 status_update_manager.cpp:162] New master detected at master@192.168.122.164:47130 I0213 22:15:39.970116 17384 master.cpp:1840] Attempting to register slave on fedora-20 at slave(1)@192.168.122.164:47130 I0213 22:15:39.970130 17384 master.cpp:2810] Adding slave 2014-02-13-22:15:39-2759502016-47130-17373-0 at fedora-20 with cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] I0213 22:15:39.970213 17384 slave.cpp:440] Registered with master master@192.168.122.164:47130; given slave ID 2014-02-13-22:15:39-2759502016-47130-17373-0 I0213 22:15:39.970365 17384 slave.cpp:453] Checkpointing SlaveInfo to '/tmp/mesos-KG9dIs/0/meta/slaves/2014-02-13-22:15:39-2759502016-47130-17373-0/slave.info' I0213 22:15:39.971178 17382 hierarchical_allocator_process.hpp:445] Added slave 2014-02-13-22:15:39-2759502016-47130-17373-0 (fedora-20) with cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] (and cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] available) I0213 22:15:39.971231 17382 hierarchical_allocator_process.hpp:708] Performed allocation for slave 2014-02-13-22:15:39-2759502016-47130-17373-0 in 9023ns I0213 22:15:39.972479 17373 containerizer.cpp:180] Using isolation: posix/cpu,posix/mem I0213 22:15:39.973124 17381 slave.cpp:112] Slave started on 2)@192.168.122.164:47130 I0213 22:15:39.973276 17381 slave.cpp:122] Slave resources: cpus(*):1; mem(*):979; disk(*):1001; ports(*):[31000-32000] I0213 22:15:39.974185 17381 slave.cpp:150] Slave hostname: fedora-20 I0213 22:15:39.974202 17381 slave.cpp:151] Slave checkpoint: true I0213 22:15:39.975014 17381 state.cpp:33] Recovering state from '/tmp/mesos-KG9dIs/1/meta' I0213 22:15:39.975071 17381 status_update_manager.cpp:188] Recovering status update manager I0213 22:15:39.975098 17381 mesos_containerizer.cpp:137] Recovering containerizer I0213 22:15:39.975219 17381 slave.cpp:2670] Finished recovery I0213 22:15:39.976111 17381 slave.cpp:397] New master detected at master@192.168.122.164:47130 I0213 22:15:39.976758 17381
[jira] [Commented] (MESOS-1750) ImportError in containerizer_pb2.py
[
https://issues.apache.org/jira/browse/MESOS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119530#comment-14119530
]
Till Toenshoff commented on MESOS-1750:
---
That was exactly the only solution I could come up with so far as well;
patching the python proto results after they have been rendered. Not really
beautiful solution but maybe the only option we got other than changing the
proto locations which seems just wrong considering that we would have to mix
all proto-files into one flat folder (including the internal proto's for
allowing MESOS-1731 to happen).
ImportError in containerizer_pb2.py
---
Key: MESOS-1750
URL: https://issues.apache.org/jira/browse/MESOS-1750
Project: Mesos
Issue Type: Bug
Components: python api
Reporter: Till Toenshoff
Labels: mesos.interface, python-egg
It appears as if the split of the Python egg (native/interface/protocol) has
introduced a new issue.
Whenever I am trying to use {{from mesos.interface import
containerizer_pb2}}, I am receiving an {{ImportError: No module named
mesos_pb2}}.
For replicating this issue, try running
{{build/src/examples/python/test-containerizer}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1750) ImportError in containerizer_pb2.py
[
https://issues.apache.org/jira/browse/MESOS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14120175#comment-14120175
]
Till Toenshoff edited comment on MESOS-1750 at 9/3/14 7:13 PM:
---
So the following does the job...
{noformat}
python/interface/src/mesos/interface/containerizer_pb2.py:
\
$(CONTAINERIZER_PROTO)
$(MKDIR_P) $(@D)
$(PROTOC) -I$(top_srcdir)/include/mesos/containerizer \
$(PROTOCFLAGS)
\
--python_out=python/interface/src/mesos/interface $^
sed -i '' -e 's/mesos\.mesos_pb2/mesos_pb2/' $^
{noformat}
However, I still feel that this is not really *correct* and that we should
possibly take a step back for finding a proper solution.
Another solution would be adapting the {{mesos/interface}} structure towards a
non flat hierachy:
{noformat}
mesos/mesos_pb2.py
mesos/containerizer/containerizer_pb2.py
{noformat}
Resulting into rather verbose looking python imports like:
{noformat}
from mesos.interface.mesos.containerizer import containerizer_pb2
from mesos.interface.mesos import mesos_pb2
{noformat}
The above maintains the exact namespace structure we are using for all other
bindings (but adds {{mesos.interface}} as a prefix).
I do not see any other options right now and I really would like to ask for
comments on this.
was (Author: tillt):
So the following does the job...
{noformat}
python/interface/src/mesos/interface/containerizer_pb2.py:
\
$(CONTAINERIZER_PROTO)
$(MKDIR_P) $(@D)
$(PROTOC) -I$(top_srcdir)/include/mesos/containerizer \
$(PROTOCFLAGS)
\
--python_out=python/interface/src/mesos/interface $^
sed -i -e 's/mesos\.mesos_pb2/mesos_pb2/' $^
{noformat}
However, I still feel that this is not really *correct* and that we should
possibly take a step back for finding a proper solution.
Another solution would be adapting the {{mesos/interface}} structure towards a
non flat hierachy:
{noformat}
mesos/mesos_pb2.py
mesos/containerizer/containerizer_pb2.py
{noformat}
Resulting into rather verbose looking python imports like:
{noformat}
from mesos.interface.mesos.containerizer import containerizer_pb2
from mesos.interface.mesos import mesos_pb2
{noformat}
The above maintains the exact namespace structure we are using for all other
bindings (but adds {{mesos.interface}} as a prefix).
I do not see any other options right now and I really would like to ask for
comments on this.
ImportError in containerizer_pb2.py
---
Key: MESOS-1750
URL: https://issues.apache.org/jira/browse/MESOS-1750
Project: Mesos
Issue Type: Bug
Components: python api
Reporter: Till Toenshoff
Labels: mesos.interface, python-egg
It appears as if the split of the Python egg (native/interface/protocol) has
introduced a new issue.
Whenever I am trying to use {{from mesos.interface import
containerizer_pb2}}, I am receiving an {{ImportError: No module named
mesos_pb2}}.
For replicating this issue, try running
{{build/src/examples/python/test-containerizer}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1745) Building Python egg on OS X using clang is problematic
[
https://issues.apache.org/jira/browse/MESOS-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121133#comment-14121133
]
Till Toenshoff commented on MESOS-1745:
---
[~jieyu] could you post the results of {{python-config --ldflags}} please?
Building Python egg on OS X using clang is problematic
--
Key: MESOS-1745
URL: https://issues.apache.org/jira/browse/MESOS-1745
Project: Mesos
Issue Type: Bug
Affects Versions: 0.19.1
Environment: Mac OS X 10.8.5
clang-3.3 installed via brew
python 2.7.8 install via brew ([GCC 4.2.1 Compatible Apple LLVM 4.2
(clang-425.0.28)])
Reporter: Jie Yu
Here is what I have observed, correct me if I am wrong.
To reproduce:
{noformat}
$ tar zxvf mesos-0.19.1.tar.gz
$ cd mesos-0.19.1
$ mkdir build
$ cd build
$ CC=clang-3.3 CXX=clang++-3.3 ../configure
$ make
$ PYTHONPATH=src/python/dist/mesos-0.19.1-py2.7-macosx-10.8-x86_64.egg python
Python 2.7.8 (default, Aug 18 2014, 15:46:02)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type help, copyright, credits or license for more information.
import mesos
Traceback (most recent call last):
File stdin, line 1, in module
File build/bdist.macosx-10.8-x86_64/egg/mesos.py, line 26, in module
File build/bdist.macosx-10.8-x86_64/egg/_mesos.py, line 7, in module
File build/bdist.macosx-10.8-x86_64/egg/_mesos.py, line 6, in
__bootstrap__
ImportError:
dlopen(/Users/jyu/.python-eggs/mesos-0.19.1-py2.7-macosx-10.8-x86_64.egg-tmp/_mesos.so,
2): Symbol not found:
__ZN5mesos20MesosSchedulerDriverC1EPNS_9SchedulerERKNS_13FrameworkInfoERKSs
Referenced from:
/Users/jyu/.python-eggs/mesos-0.19.1-py2.7-macosx-10.8-x86_64.egg-tmp/_mesos.so
Expected in: flat namespace
in
/Users/jyu/.python-eggs/mesos-0.19.1-py2.7-macosx-10.8-x86_64.egg-tmp/_mesos.so
{noformat}
After digging this problem today, here is what I've found:
1. build/src/.libs/libmesos_no_3rdparty.a is built using clang++-3.3 with
flags -std=c++11 -stdlib=libc++. So the mangled MesosSchedulerDriver
constructor symbol is like the following in libmesos_no_3rdparty.a
{noformat}
[tw-mbp-jyu build]$ nm src/.libs/libmesos_no_3rdparty.a | grep
MesosSchedulerDriver
...
06d0 T
__ZN5mesos20MesosSchedulerDriverC1EPNS_9SchedulerERKNS_13FrameworkInfoERKNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIc
...
{noformat}
2.
build/src/python/build/temp.macosx-10.8-x86_64-2.7/native/mesos_scheduler_driver_impl.o
is built using clang++-3.3 without -stdlib=libc++
{noformat}
clang-3.3 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g
-Qunused-arguments -Qunused-arguments
-I/tmp/build/mesos-0.19.1/build/../include
-I/tmp/build/mesos-0.19.1/build/include -I/tmp/build/mesos-0.19.1/build/src
-I/tmp/bui
ld/mesos-0.19.1/build/src/python/native
-I/tmp/build/mesos-0.19.1/build/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
-I/opt/twitter/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/include/python2.7
-c native/mesos_
scheduler_driver_impl.cpp -o
build/temp.macosx-10.8-x86_64-2.7/native/mesos_scheduler_driver_impl.o
{noformat}
As a result, it expects a mangled MesosSchedulerDriver constructor symbol
like the following:
{noformat}
[tw-mbp-jyu build]$ nm
src/python/build/temp.macosx-10.8-x86_64-2.7/native/mesos_scheduler_driver_impl.o
| grep MesosSchedulerDriver
U
__ZN5mesos20MesosSchedulerDriverC1EPNS_9SchedulerERKNS_13FrameworkInfoERKSs
...
{noformat}
3. As a result, the above symbol will remain 'unresolved' in _mesos.so, and
subsequently causes issue when we 'import mesos' using the egg.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1750) ImportError in containerizer_pb2.py
[
https://issues.apache.org/jira/browse/MESOS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121266#comment-14121266
]
Till Toenshoff commented on MESOS-1750:
---
So I went ahead and proposed a patch that uses sed for in-place patching of the
resulting python code: https://reviews.apache.org/r/25334/
ImportError in containerizer_pb2.py
---
Key: MESOS-1750
URL: https://issues.apache.org/jira/browse/MESOS-1750
Project: Mesos
Issue Type: Bug
Components: python api
Reporter: Till Toenshoff
Labels: mesos.interface, python-egg
It appears as if the split of the Python egg (native/interface/protocol) has
introduced a new issue.
Whenever I am trying to use {{from mesos.interface import
containerizer_pb2}}, I am receiving an {{ImportError: No module named
mesos_pb2}}.
For replicating this issue, try running
{{build/src/examples/python/test-containerizer}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1571) Signal escalation timeout is not configurable
[
https://issues.apache.org/jira/browse/MESOS-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14122858#comment-14122858
]
Till Toenshoff commented on MESOS-1571:
---
Using the environment to pass that info seems to fit best when looking at the
things we already pass (e.g. {{MESOS_RECOVERY_TIMEOUT}}), whereas the
{{SlaveInfo}} protobuf is rather limited in additional execution specific
parameters.
However to me this still raises the question on why we prefer using the
environment instead of proto's for such information. One obvious reason
certainly is that we might need to supply information that is needed
immediately before or after starting the {{ExecutorProcess}} but definitely
before it successfully registered, when {{SlaveInfo}} finally becomes available
to him. Despite my above argument being we already do it that way, are there
better arguments for not adding things to the proto but instead using the
environment for passing the additional parameters?
[~benjaminhindman], [~idownes], [~tnachen] any input for this discussion?
Signal escalation timeout is not configurable
-
Key: MESOS-1571
URL: https://issues.apache.org/jira/browse/MESOS-1571
Project: Mesos
Issue Type: Bug
Reporter: Niklas Quarfot Nielsen
Assignee: Alexander Rukletsov
Even though the executor shutdown grace period is set to a larger interval,
the signal escalation timeout will still be 3 seconds. It should either be
configurable or dependent on EXECUTOR_SHUTDOWN_GRACE_PERIOD.
Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1660) Lower ReaperProcess::wait() delay to 500ms or 250ms
[ https://issues.apache.org/jira/browse/MESOS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14144532#comment-14144532 ] Till Toenshoff commented on MESOS-1660: --- Hey Guys, this is very promising. Would you need any help to get this committed? Lower ReaperProcess::wait() delay to 500ms or 250ms --- Key: MESOS-1660 URL: https://issues.apache.org/jira/browse/MESOS-1660 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Craig Hansen-Sturm Assignee: Craig Hansen-Sturm See https://issues.apache.org/jira/browse/MESOS-1199 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14151975#comment-14151975 ] Till Toenshoff commented on MESOS-1797: --- https://issues.apache.org/jira/browse/ZOOKEEPER-2049 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.20.0, 0.21.0, 0.19.1 Reporter: Dario Rexin Priority: Minor 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 (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14152438#comment-14152438 ] Till Toenshoff commented on MESOS-1797: --- https://github.com/apache/zookeeper/pull/19.patch would be an upstream patch suggestion. I know this is kind of a red flag but given that Yosemite's release is close, should we also go ahead and include a hotfix patch within our bundle? 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.20.0, 0.21.0, 0.19.1 Reporter: Dario Rexin Priority: Minor 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 (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14152609#comment-14152609 ] Till Toenshoff commented on MESOS-1797: --- [~bmahler] +1 Hoping their unit tests are actually just flaky as my patch got flagged by them (just like many others that still got committed). 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.20.0, 0.21.0, 0.19.1 Reporter: Dario Rexin Priority: Minor 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 (v6.3.4#6332)
[jira] [Commented] (MESOS-1848) DRFAllocatorTest.DRFAllocatorProcess is flaky
[
https://issues.apache.org/jira/browse/MESOS-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14163973#comment-14163973
]
Till Toenshoff commented on MESOS-1848:
---
Turned out the described symptoms were caused by a custom sasl installation I
did on that VM. After removing all traces of it and rebuilding against a proper
one, everything went back to normal. That certainly does not really help for
pinning the problem to the exact cause but it did the job for me.
DRFAllocatorTest.DRFAllocatorProcess is flaky
-
Key: MESOS-1848
URL: https://issues.apache.org/jira/browse/MESOS-1848
Project: Mesos
Issue Type: Bug
Components: test
Environment: Fedora 20
Reporter: Vinod Kone
Observed this on CI. This is pretty strange because the authentication of
both the framework and slave timed out at the very beginning, even though we
don't manipulate clocks.
{code}
[ RUN ] DRFAllocatorTest.DRFAllocatorProcess
Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_igiR9X'
I0929 20:11:12.801327 16997 leveldb.cpp:176] Opened db in 489720ns
I0929 20:11:12.801627 16997 leveldb.cpp:183] Compacted db in 168280ns
I0929 20:11:12.801784 16997 leveldb.cpp:198] Created db iterator in 5820ns
I0929 20:11:12.801898 16997 leveldb.cpp:204] Seeked to beginning of db in
1285ns
I0929 20:11:12.802039 16997 leveldb.cpp:273] Iterated through 0 keys in the
db in 792ns
I0929 20:11:12.802160 16997 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0929 20:11:12.802441 17012 recover.cpp:425] Starting replica recovery
I0929 20:11:12.802623 17012 recover.cpp:451] Replica is in EMPTY status
I0929 20:11:12.803251 17012 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I0929 20:11:12.803427 17012 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I0929 20:11:12.803632 17012 recover.cpp:542] Updating replica status to
STARTING
I0929 20:11:12.803911 17012 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 33999ns
I0929 20:11:12.804033 17012 replica.cpp:320] Persisted replica status to
STARTING
I0929 20:11:12.804245 17012 recover.cpp:451] Replica is in STARTING status
I0929 20:11:12.804592 17012 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I0929 20:11:12.804775 17012 recover.cpp:188] Received a recover response from
a replica in STARTING status
I0929 20:11:12.804952 17012 recover.cpp:542] Updating replica status to VOTING
I0929 20:11:12.805115 17012 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 15990ns
I0929 20:11:12.805234 17012 replica.cpp:320] Persisted replica status to
VOTING
I0929 20:11:12.805366 17012 recover.cpp:556] Successfully joined the Paxos
group
I0929 20:11:12.805539 17012 recover.cpp:440] Recover process terminated
I0929 20:11:12.809062 17017 master.cpp:312] Master
20140929-201112-2759502016-47295-16997 (fedora-20) started on
192.168.122.164:47295
I0929 20:11:12.809432 17017 master.cpp:358] Master only allowing
authenticated frameworks to register
I0929 20:11:12.809546 17017 master.cpp:363] Master only allowing
authenticated slaves to register
I0929 20:11:12.810169 17017 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/DRFAllocatorTest_DRFAllocatorProcess_igiR9X/credentials'
I0929 20:11:12.810510 17017 master.cpp:392] Authorization enabled
I0929 20:11:12.811841 17016 master.cpp:120] No whitelist given. Advertising
offers for all slaves
I0929 20:11:12.812099 17013 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@192.168.122.164:47295
I0929 20:11:12.813006 17017 master.cpp:1241] The newly elected leader is
master@192.168.122.164:47295 with id 20140929-201112-2759502016-47295-16997
I0929 20:11:12.813164 17017 master.cpp:1254] Elected as the leading master!
I0929 20:11:12.813279 17017 master.cpp:1072] Recovering from registrar
I0929 20:11:12.813487 17013 registrar.cpp:312] Recovering registrar
I0929 20:11:12.813824 17013 log.cpp:656] Attempting to start the writer
I0929 20:11:12.814256 17013 replica.cpp:474] Replica received implicit
promise request with proposal 1
I0929 20:11:12.814419 17013 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 25049ns
I0929 20:11:12.814581 17013 replica.cpp:342] Persisted promised to 1
I0929 20:11:12.814909 17013 coordinator.cpp:230] Coordinator attemping to
fill missing position
I0929 20:11:12.815340 17013 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I0929 20:11:12.815497 17013 leveldb.cpp:343] Persisting action (8 bytes) to
leveldb took 19855ns
I0929 20:11:12.815636 17013
[jira] [Created] (MESOS-1889) Create an Authenticatior Module
Till Toenshoff created MESOS-1889: - Summary: Create an Authenticatior Module Key: MESOS-1889 URL: https://issues.apache.org/jira/browse/MESOS-1889 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Breaking this down into several tickets for allowing dedicated discussions where needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1891) Authenticator Module: Interface design
Till Toenshoff created MESOS-1891:
-
Summary: Authenticator Module: Interface design
Key: MESOS-1891
URL: https://issues.apache.org/jira/browse/MESOS-1891
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
The current sasl based, flat-file Authenticator ( {{sasl/authenticator.hpp}}
) is spawning a (libprocess) process in its constructor and demands the
authentication client process UPID as a parameter - not a perfect fit for the
current Module API as that one does only allow default constructors.
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change the
current design into a feasible interface, no?
I would like to propose something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID clientPid) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1891) Authenticator Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1891:
--
Description:
h4. Motivation
Design an interface covering authenticator modules while staying minimal
invasive in regards to changes on the existing flat-file Authenticator
implementation.
h4. Status Quo
The current sasl based, flat-file Authenticator ( {{sasl/authenticator.hpp}}
) is spawning a (libprocess) process in its constructor and demands the
authentication client process UPID as a parameter - not a perfect fit for the
current Module API as that one does only allow default constructors.
h4. Design
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change the
current design into a feasible interface, no?
I would like to propose something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID clientPid) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
was:
The current sasl based, flat-file Authenticator ( {{sasl/authenticator.hpp}}
) is spawning a (libprocess) process in its constructor and demands the
authentication client process UPID as a parameter - not a perfect fit for the
current Module API as that one does only allow default constructors.
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change the
current design into a feasible interface, no?
I would like to propose something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID clientPid) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
Authenticator Module: Interface design
--
Key: MESOS-1891
URL: https://issues.apache.org/jira/browse/MESOS-1891
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Design an interface covering authenticator modules while staying minimal
invasive in regards to changes on the existing flat-file Authenticator
implementation.
h4. Status Quo
The current sasl based, flat-file Authenticator (
{{sasl/authenticator.hpp}} ) is spawning a (libprocess) process in its
constructor and demands the authentication client process UPID as a parameter
- not a perfect fit for the current Module API as that one does only allow
default constructors.
h4. Design
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change
the current design into a feasible interface, no?
I would like to propose something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID clientPid) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1889: -- Description: Breaking this down into several tickets for allowing dedicated discussions where needed. - [Interface Design|https://issues.apache.org/jira/browse/MESOS-1891] - [Location and Naming|https://issues.apache.org/jira/browse/MESOS-1893] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] was:Breaking this down into several tickets for allowing dedicated discussions where needed. 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 Breaking this down into several tickets for allowing dedicated discussions where needed. - [Interface Design|https://issues.apache.org/jira/browse/MESOS-1891] - [Location and Naming|https://issues.apache.org/jira/browse/MESOS-1893] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1895) Enable cgroups isolation by default
[ https://issues.apache.org/jira/browse/MESOS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1895: -- Issue Type: Improvement (was: Bug) Enable cgroups isolation by default --- Key: MESOS-1895 URL: https://issues.apache.org/jira/browse/MESOS-1895 Project: Mesos Issue Type: Improvement Components: slave Affects Versions: 0.20.1 Environment: Linux! Reporter: Sunil Shah cgroups isolation is not enabled by default on mesos-slave. For people deploying Mesos in a production environment, it makes sense that this would default - given the assumption that Mesos uses cgroups to isolate running tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1889: -- Description: 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] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] was: Breaking this down into several tickets for allowing dedicated discussions where needed. - [Interface Design|https://issues.apache.org/jira/browse/MESOS-1891] - [Location and Naming|https://issues.apache.org/jira/browse/MESOS-1893] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] 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 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] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14165944#comment-14165944 ] Till Toenshoff commented on MESOS-1889: --- Great points guys. I have updated this ticket to reflect the motivation behind this improvement as a whole. 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 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] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1896) Enable module specific command line parameters
Till Toenshoff created MESOS-1896:
-
Summary: Enable module specific command line parameters
Key: MESOS-1896
URL: https://issues.apache.org/jira/browse/MESOS-1896
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
h4. Idea
Add a flags parameter to the create call and hand down textual or parsed JSON
to the module. The JSON on the command line can either a) be associated with
the module mention or it can b) be associated with the module kind's topic or
c) have a separate flags section just for module flags.
Opinions?
h4. Examples (prototyping, not claiming this grammar is ideal):
a) {noformat}slave --modules='[{lib : path, modules : [{name : myModule,
flags : '{credentials : foo}}]}]'{noformat}
b) {noformat}slave --modules='[{lib : path, modules : [
{myModule}]}]' --authenticatorFlags='{credentials : foo}'{noformat}
c) {noformat}slave --modules='[{lib : path, modules : [{myModule}
]}]' --moduleFlags='[{module : myModule, flags :
{credentials : foo}
]}{noformat}
In any case modules could report their required flags syntax when calling
{noformat}slave --help --modules='[{lib : path, modules : [
{myModule} ]}]'{noformat} or something like that in any of the above variants.
This was copied from Bernd's comment on MESOS-1384.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1894) Authenticator Module: Tests
[
https://issues.apache.org/jira/browse/MESOS-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1894:
--
Component/s: modules
Authenticator Module: Tests
---
Key: MESOS-1894
URL: https://issues.apache.org/jira/browse/MESOS-1894
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
There are no unit tests for authenticator or authenticatee so far. We
currently have a few authentication integration tests (
{{tests/sasl_tests.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. provide a unit test for the flatfile authenticator module
3. implement integration tests via a parameterized version of
{{sasl_tests.cpp}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1893) Authenticator Module: Location and Naming
[
https://issues.apache.org/jira/browse/MESOS-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1893:
--
Description:
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall be
similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a whole,
I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/cram_md5/authenticator/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{cram_md5}} instead of {{sasl}} due to the fact
that cyrus-sasl2 offers many more mechanisms but our current default (CRAM-MD5)
and further dividing the tree into sasl and non-sasl based authentications may
be too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_crammd5}} to be used for our first/default
Authenticator.
was:
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall be
similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a whole,
I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
- create a new {{authentication/authenticator/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/authenticator/flatfile/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{flatfile}} instead of {{sasl}} due to the fact
that sasl offers many more mechanisms but our current default (CRAM-MD5) and
further dividing the tree into sasl and non-sasl based authentications may be
too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_flatfile}} to be used for our first/default
Authenticator.
Authenticator Module: Location and Naming
-
Key: MESOS-1893
URL: https://issues.apache.org/jira/browse/MESOS-1893
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall
be similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a
whole, I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/cram_md5/authenticator/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{cram_md5}} instead of {{sasl}} due to the fact
that cyrus-sasl2 offers many more mechanisms but our current default
(CRAM-MD5) and further dividing the tree into sasl and non-sasl based
authentications may be too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_crammd5}} to be used for our first/default
Authenticator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1893) Authenticator Module: Location and Naming
[
https://issues.apache.org/jira/browse/MESOS-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1893:
--
Description:
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall be
similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a whole,
I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/cram_md5/authenticator/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{cram_md5}} instead of {{sasl}} due to the fact
that cyrus-sasl2 offers many more mechanisms but our current default (CRAM-MD5)
and further dividing the tree into sasl and non-sasl based authentications may
be too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_crammd5}} to be used for our first/default
Authenticator. Mind that in this case I did not reflect the folder tree into
this reverse domain alike description as I find it more intuitive to have the
module before the kind - objections?
was:
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall be
similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a whole,
I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/cram_md5/authenticator/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{cram_md5}} instead of {{sasl}} due to the fact
that cyrus-sasl2 offers many more mechanisms but our current default (CRAM-MD5)
and further dividing the tree into sasl and non-sasl based authentications may
be too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_crammd5}} to be used for our first/default
Authenticator.
Authenticator Module: Location and Naming
-
Key: MESOS-1893
URL: https://issues.apache.org/jira/browse/MESOS-1893
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Render a well structured and mesos-alike naming and folder tree. This shall
be similar to what we know from the awesome! containerizer structure.
h4. Folder Structure
For the flat-file Authenticator Module but also for authentication as a
whole, I would like to propose the following structural changes:
- move {{authenticator.hpp}} out of {{sasl/}}
- create a new {{authentication/}}
-- put the module interface here and name it {{authenticator.hpp}}
- create a new {{authentication/cram_md5/authenticator/}}
-- put the module implementation here and name it {{authenticator.hpp}}
-- mind that I am proposing {{cram_md5}} instead of {{sasl}} due to the fact
that cyrus-sasl2 offers many more mechanisms but our current default
(CRAM-MD5) and further dividing the tree into sasl and non-sasl based
authentications may be too verbosive/bloated.
h4. Module Naming
Following the module naming scheme, I would like to propose
{{org_apache_mesos_authenticator_crammd5}} to be used for our first/default
Authenticator. Mind that in this case I did not reflect the folder tree into
this reverse domain alike description as I find it more intuitive to have the
module before the kind - objections?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-1905) Enable module metadata to be accessed by the user
Till Toenshoff created MESOS-1905:
-
Summary: Enable module metadata to be accessed by the user
Key: MESOS-1905
URL: https://issues.apache.org/jira/browse/MESOS-1905
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Priority: Blocker
h4. Motivation
I would love to be able to get custom, meta-data information from a module
without needing to create a kind instance.
h4. Use Case
When slave authentication is activated on the master, the user has to supply
credentials (as our current implementation demands them). Given that
alternative authentications will not rely on such credentials, we need a way to
make sure that only Authenticator's that need this information will demand them
from the user. I would like to prevent instantiating a kind for that module as
I will not make further use of that instance at that (early) point - let me
call this the capabilities instance.
Options are; (a) delete it right away or (b) hold on to it.
a: definitely is possible but does not seem elegant to me right now.
b: holding on onto that instance and reusing it later is not really a good fit
as the master will instantiate new Authenticator's per connected slave. So for
the first slave, I would have to use that capabilities instance and for all
further slave connections I would have to create new Authenticators (possible
but ugly as hell).
So by extending the Module structure specialization, I could solve this rather
neatly:
{noformat}
template
struct ModuleAuthenticator : ModuleBase
{
Module(
const char* _moduleApiVersion,
const char* _mesosVersion,
const char* _authorName,
const char* _authorEmail,
const char* _description,
bool (*_compatible)(),
bool (*_needsCredentials)(),
Authenticator* (*_create)())
: ModuleBase(
_moduleApiVersion,
_mesosVersion,
Authenticator,
_authorName,
_authorEmail,
_description,
_compatible),
needsCredentials(_needsCredentials),
create(_create)
{ }
bool (*needsCredentials)();
Authenticator* (*create)();
};
{noformat}
Within the implementation I would simply use that function just like we are
using {{compatible()}} already.
h4. Status Quo
ModuleManager does not support returning the {{ModuleBase*}} to the user. The
only way for such information to be returned by a module is to instantiate it
and ask its implementation for it - that is, the module interface needs to
include a method returning such info.
h4. Idea
For being able to get information on a module without an instance kind, a
method within the ModuleManager that looks something like this would help:
{noformat}
static TryModuleBase* peek(const std::string moduleName)
{noformat}
h4. Discussion
Am I possibly attempting something too hacky here - are there better
alternatives I missed?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14167804#comment-14167804 ] Till Toenshoff commented on MESOS-1797: --- [~xujyan] Would you be available for shepparding https://reviews.apache.org/r/26571 which should fix the above issue? Note however that we still intend to wait for upstream to commit this patch into their project - hence the above RR would be a hotfix to prevent us from having to upgrade the bundled ZooKeeper altogether. 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.20.0, 0.21.0, 0.19.1 Reporter: Dario Rexin Priority: Minor 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 (v6.3.4#6332)
[jira] [Updated] (MESOS-1894) Authenticator Module: Tests
[
https://issues.apache.org/jira/browse/MESOS-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1894:
--
Description:
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole ( {{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
was:
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
There are no unit tests for authenticator or authenticatee so far. We currently
have a few authentication integration tests ( {{tests/sasl_tests.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. provide a unit test for the flatfile authenticator module
3. implement integration tests via a parameterized version of {{sasl_tests.cpp}}
Authenticator Module: Tests
---
Key: MESOS-1894
URL: https://issues.apache.org/jira/browse/MESOS-1894
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole ( {{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1894) Authenticator Module: Tests
[
https://issues.apache.org/jira/browse/MESOS-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1894:
--
Description:
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole with some CRAM-MD5 specifics again (
{{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}} {{tests/authentication.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
was:
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole ( {{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
Authenticator Module: Tests
---
Key: MESOS-1894
URL: https://issues.apache.org/jira/browse/MESOS-1894
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole with some CRAM-MD5 specifics again (
{{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}} {{tests/authentication.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1905) Enable module metadata to be accessed by the user
[
https://issues.apache.org/jira/browse/MESOS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172253#comment-14172253
]
Till Toenshoff commented on MESOS-1905:
---
Turns out I can get around without this feature by a minor change in the
flags-validation within mesos-master. So my specific use-case becomes invalid
for now.
Given that the basic idea might still be useful when properly being expanded
(versioning on the information channel), I will not close this unless
instructed otherwise.
Enable module metadata to be accessed by the user
-
Key: MESOS-1905
URL: https://issues.apache.org/jira/browse/MESOS-1905
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Priority: Blocker
h4. Motivation
I would love to be able to get custom, meta-data information from a module
without needing to create a kind instance.
h4. Use Case
When slave authentication is activated on the master, the user has to supply
credentials (as our current implementation demands them). Given that
alternative authentications will not rely on such credentials, we need a way
to make sure that only Authenticator's that need this information will demand
them from the user. I would like to prevent instantiating a kind for that
module as I will not make further use of that instance at that (early) point
- let me call this the capabilities instance.
Options are; (a) delete it right away or (b) hold on to it.
a: definitely is possible but does not seem elegant to me right now.
b: holding on onto that instance and reusing it later is not really a good
fit as the master will instantiate new Authenticator's per connected slave.
So for the first slave, I would have to use that capabilities instance and
for all further slave connections I would have to create new Authenticators
(possible but ugly as hell).
So by extending the Module structure specialization with a {{bool
needsCredentials()}}, I could solve this rather neatly:
{noformat}
template
struct ModuleAuthenticator : ModuleBase
{
Module(
const char* _moduleApiVersion,
const char* _mesosVersion,
const char* _authorName,
const char* _authorEmail,
const char* _description,
bool (*_compatible)(),
bool (*_needsCredentials)(),
Authenticator* (*_create)())
: ModuleBase(
_moduleApiVersion,
_mesosVersion,
Authenticator,
_authorName,
_authorEmail,
_description,
_compatible),
needsCredentials(_needsCredentials),
create(_create)
{ }
bool (*needsCredentials)();
Authenticator* (*create)();
};
{noformat}
Within the implementation I would simply use that function just like we are
using {{compatible()}} already.
h4. Status Quo
ModuleManager does not support returning the {{ModuleBase*}} to the user. The
only way for such information to be returned by a module is to instantiate it
and ask its implementation for it - that is, the module interface needs to
include a method returning such info.
h4. Idea
For being able to get information on a module without an instance kind, a
method within the ModuleManager that looks something like this would help:
{noformat}
static TryModuleBase* peek(const std::string moduleName)
{noformat}
h4. Discussion
Am I possibly attempting something too hacky here - are there better
alternatives I missed?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1905) Enable module metadata to be accessed by the user
[
https://issues.apache.org/jira/browse/MESOS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1905:
--
Priority: Minor (was: Blocker)
Enable module metadata to be accessed by the user
-
Key: MESOS-1905
URL: https://issues.apache.org/jira/browse/MESOS-1905
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Priority: Minor
h4. Motivation
I would love to be able to get custom, meta-data information from a module
without needing to create a kind instance.
h4. Use Case
When slave authentication is activated on the master, the user has to supply
credentials (as our current implementation demands them). Given that
alternative authentications will not rely on such credentials, we need a way
to make sure that only Authenticator's that need this information will demand
them from the user. I would like to prevent instantiating a kind for that
module as I will not make further use of that instance at that (early) point
- let me call this the capabilities instance.
Options are; (a) delete it right away or (b) hold on to it.
a: definitely is possible but does not seem elegant to me right now.
b: holding on onto that instance and reusing it later is not really a good
fit as the master will instantiate new Authenticator's per connected slave.
So for the first slave, I would have to use that capabilities instance and
for all further slave connections I would have to create new Authenticators
(possible but ugly as hell).
So by extending the Module structure specialization with a {{bool
needsCredentials()}}, I could solve this rather neatly:
{noformat}
template
struct ModuleAuthenticator : ModuleBase
{
Module(
const char* _moduleApiVersion,
const char* _mesosVersion,
const char* _authorName,
const char* _authorEmail,
const char* _description,
bool (*_compatible)(),
bool (*_needsCredentials)(),
Authenticator* (*_create)())
: ModuleBase(
_moduleApiVersion,
_mesosVersion,
Authenticator,
_authorName,
_authorEmail,
_description,
_compatible),
needsCredentials(_needsCredentials),
create(_create)
{ }
bool (*needsCredentials)();
Authenticator* (*create)();
};
{noformat}
Within the implementation I would simply use that function just like we are
using {{compatible()}} already.
h4. Status Quo
ModuleManager does not support returning the {{ModuleBase*}} to the user. The
only way for such information to be returned by a module is to instantiate it
and ask its implementation for it - that is, the module interface needs to
include a method returning such info.
h4. Idea
For being able to get information on a module without an instance kind, a
method within the ModuleManager that looks something like this would help:
{noformat}
static TryModuleBase* peek(const std::string moduleName)
{noformat}
h4. Discussion
Am I possibly attempting something too hacky here - are there better
alternatives I missed?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-1926) Enable local cluster to use module loading.
Till Toenshoff created MESOS-1926: - Summary: 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: Blocker This appears to break down into two issues; launch: Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable sched.cpp to load modules. mesos-local: Enable loadable modules within the executable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 ] Till Toenshoff updated MESOS-1926: -- Description: This appears to break down into two issues; launch: Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. mesos-local: Enable loadable modules within the executable via changes in local/main.cpp. was: This appears to break down into two issues; launch: Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable sched.cpp to load modules. mesos-local: Enable loadable modules within the executable. 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: Blocker This appears to break down into two issues; launch: Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. mesos-local: Enable loadable modules within the executable via changes in local/main.cpp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1927) Enable implicit local cluster launch to load modules
Till Toenshoff created MESOS-1927: - Summary: Enable implicit local cluster launch to load modules Key: MESOS-1927 URL: https://issues.apache.org/jira/browse/MESOS-1927 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1928) Enable mesos-local to load modules
Till Toenshoff created MESOS-1928: - Summary: Enable mesos-local to load modules Key: MESOS-1928 URL: https://issues.apache.org/jira/browse/MESOS-1928 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Enable loadable modules within the mesos-local executable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 ] Till Toenshoff updated MESOS-1926: -- Description: This appears to break down into two issues; launch: 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. was: This appears to break down into two issues; launch: Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. mesos-local: Enable loadable modules within the executable via changes in local/main.cpp. 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: Blocker This appears to break down into two issues; launch: 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 (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-1872) Cleanup right angle bracket in the code base.
[
https://issues.apache.org/jira/browse/MESOS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172803#comment-14172803
]
Till Toenshoff edited comment on MESOS-1872 at 10/15/14 7:18 PM:
-
Evelina has bravely proposed three review requests (mesos/libprocess/stout) for
covering the ticket. There is however some greater risk involved and I wanted
to be sure that we are all aware of the pro’s and con's of such big cleanups.
{{+}} we may need to do cleanups - even major ones at some point, hence I think
we need a consensus once and for all regarding tickets of the above nature
{{-}} almost all existing RRs will possibly get invalid and everyone with work
in flight needs to rebase (possibly rather tedious task in particular case).
There may be more.
The only way I can currently see this happening with minimal friction is
finding a certain date and even time for doing this on a very quick,
propose/review/commit.
What do you think?
was (Author: tillt):
Evelina has bravely proposed three review requests (mesos/libprocess/stout) for
covering the ticket. There is however some greater risk involved and I wanted
to be sure that we are all aware of the pro’s and con's of such big cleanups.
+ we may need to do cleanups - even major ones at some point, hence I think we
need a consensus once and for all regarding tickets of the above nature
- almost all existing RRs will possibly get invalid and everyone with work in
flight needs to rebase (possibly rather tedious task in particular case).
There may be more.
The only way I can currently see this happening with minimal friction is
finding a certain date and even time for doing this on a very quick,
propose/review/commit.
What do you think?
Cleanup right angle bracket in the code base.
-
Key: MESOS-1872
URL: https://issues.apache.org/jira/browse/MESOS-1872
Project: Mesos
Issue Type: Bug
Reporter: Jie Yu
Assignee: Evelina Dumitrescu
Labels: c++11, newbie
As we start to use c++11 style right angle brackets ('' instead of ' '):
https://reviews.apache.org/r/25861
We should do a sweep in our code base to make it consistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1927) Enable implicit local cluster launch to load modules
[ https://issues.apache.org/jira/browse/MESOS-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172946#comment-14172946 ] Till Toenshoff commented on MESOS-1927: --- https://reviews.apache.org/r/26775/ Enable implicit local cluster launch to load modules Key: MESOS-1927 URL: https://issues.apache.org/jira/browse/MESOS-1927 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1939) Enable multiple authentication methods in parallel
Till Toenshoff created MESOS-1939: - Summary: Enable multiple authentication methods in parallel Key: MESOS-1939 URL: https://issues.apache.org/jira/browse/MESOS-1939 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Priority: Minor The master (authenticator) should allow for multiple authentication mechanisms to be used at the same time. That way, a slave could be authenticated by mechanism FOO while the frameworks are authenticated by BAR. The authenticatee should be allowed to select the desired mechanism (module). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1891) Authenticator Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1891:
--
Description:
h4. Motivation
Design an interface covering authenticator modules while staying minimal
invasive in regards to changes on the existing flat-file Authenticator
implementation.
h4. Status Quo
The current sasl based, flat-file Authenticator ( {{sasl/authenticator.hpp}}
) is spawning a (libprocess) process in its constructor and demands the
authentication client process UPID as a parameter - not a perfect fit for the
current Module API as that one does only allow default constructors.
h4. Design
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change the
current design into a feasible interface, no?
I would like to propose this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual OptionError initialize(const process::UPID clientPid, const
OptionCredentials credentials) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
was:
h4. Motivation
Design an interface covering authenticator modules while staying minimal
invasive in regards to changes on the existing flat-file Authenticator
implementation.
h4. Status Quo
The current sasl based, flat-file Authenticator ( {{sasl/authenticator.hpp}}
) is spawning a (libprocess) process in its constructor and demands the
authentication client process UPID as a parameter - not a perfect fit for the
current Module API as that one does only allow default constructors.
h4. Design
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change the
current design into a feasible interface, no?
I would like to propose something like this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual void initialize(const process::UPID clientPid) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
Authenticator Module: Interface design
--
Key: MESOS-1891
URL: https://issues.apache.org/jira/browse/MESOS-1891
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Design an interface covering authenticator modules while staying minimal
invasive in regards to changes on the existing flat-file Authenticator
implementation.
h4. Status Quo
The current sasl based, flat-file Authenticator (
{{sasl/authenticator.hpp}} ) is spawning a (libprocess) process in its
constructor and demands the authentication client process UPID as a parameter
- not a perfect fit for the current Module API as that one does only allow
default constructors.
h4. Design
Instead of wrapping the flat-file Authenticator with yet another class that
satisfies a proper interface design, we might just as well slightly change
the current design into a feasible interface, no?
I would like to propose this:
{noformat}
class Authenticator
{
public:
Authenticator() {}
virtual ~Authenticator() {}
virtual OptionError initialize(const process::UPID clientPid, const
OptionCredentials credentials) = 0;
virtual process::FutureOptionstd::string authenticate(void) = 0;
};
{noformat}
As a result, the flat-file authenticator would spawn its process within that
proposed initialize method and not within the constructor already.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1010) Python extension build is broken if gflags-dev is installed
[
https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175977#comment-14175977
]
Till Toenshoff commented on MESOS-1010:
---
[~kevints] I am seeing this as well and I am currently trying to locate the
cause.
Python extension build is broken if gflags-dev is installed
---
Key: MESOS-1010
URL: https://issues.apache.org/jira/browse/MESOS-1010
Project: Mesos
Issue Type: Bug
Components: build, python api
Environment: Fedora 20, amd64. GCC: 4.8.2.
Reporter: Nikita Vetoshkin
In my environment mesos build from master results in broken python api module
{{_mesos.so}}:
{noformat}
nekto0n@ya-darkstar ~/workspace/mesos/src/python $
PYTHONPATH=build/lib.linux-x86_64-2.7/ python -c import _mesos
Traceback (most recent call last):
File string, line 1, in module
ImportError:
/home/nekto0n/workspace/mesos/src/python/build/lib.linux-x86_64-2.7/_mesos.so:
undefined symbol: _ZN6google14FlagRegistererC1EPKcS2_S2_S2_PvS3_
{noformat}
Unmangled version of symbol looks like this:
{noformat}
google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*,
char const*, void*, void*)
{noformat}
During {{./configure}} step {{glog}} finds {{gflags}} development files and
starts using them, thus *implicitly* adding dependency on {{libgflags.so}}.
This breaks Python extensions module and perhaps can break other mesos
subsystems when moved to hosts without {{gflags}} installed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1896) Enable module specific command line parameters
[
https://issues.apache.org/jira/browse/MESOS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178110#comment-14178110
]
Till Toenshoff commented on MESOS-1896:
---
[~karya] +1
Enable module specific command line parameters
---
Key: MESOS-1896
URL: https://issues.apache.org/jira/browse/MESOS-1896
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Kapil Arya
h4. Idea
Add a flags parameter to the create call and hand down textual or parsed JSON
to the module. The JSON on the command line can either a) be associated with
the module mention or it can b) be associated with the module kind's topic or
c) have a separate flags section just for module flags.
Opinions?
h4. Examples (prototyping, not claiming this grammar is ideal):
a) {noformat}slave --modules='[{lib : path, modules : [{name : myModule,
flags : '{credentials : foo}}]}]'{noformat}
b) {noformat}slave --modules='[{lib : path, modules : [
{myModule}]}]' --authenticatorFlags='{credentials : foo}'{noformat}
c) {noformat}slave --modules='[{lib : path, modules : [{myModule}
]}]' --moduleFlags='[{module : myModule, flags :
{credentials : foo}
]}{noformat}
In any case modules could report their required flags syntax when calling
{noformat}slave --help --modules='[{lib : path, modules : [
{myModule} ]}]'{noformat} or something like that in any of the above
variants.
This was copied from Bernd's comment on MESOS-1384.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1889: -- Sprint: Mesosphere Q4 Sprint 1 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 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] - [Tests|https://issues.apache.org/jira/browse/MESOS-1894] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-1966) Integrate the Authenticator module
Till Toenshoff created MESOS-1966: - Summary: Integrate the Authenticator module Key: MESOS-1966 URL: https://issues.apache.org/jira/browse/MESOS-1966 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff There are some options we quickly need to decide upon: 1. Keep the currently existing authenticator (sasl/authenticator.hpp) within libmesos as a default implementation. Add the --authenticators flag to the master and if the user selects crammd5, use the linked in, default implementation. If the user selects a different name e.g. org_apache_mesos_authenticator_pam, the master will try to load a module with that name and use its implemenation. This is somewhat similar to what Kapil has done with the Isolator module integration. 2. Make the currently existing authenticator become a module and thereby remove it from libmesos. Add the --authenticators flag to the master and ask the user to supply a module as well (--modules). 3. Mixture of 1. and 2. Difference to 2. would be that we load the authenticator module implicitly (without the user supplying the --modules flag) as soon as he has enabled any kind of authentication (--authenticate_slaves / --authenticate_frameworks). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1966) Integrate the Authenticator module
[
https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-1966:
--
Description:
There are some options we quickly need to decide upon:
1. Keep the currently existing authenticator {{sasl/authenticator.hpp}} within
{{libmesos}} as a default implementation. Add the {{--authenticators}} flag to
the master and if the user selects {{crammd5}}, use the linked in, default
implementation. If the user selects a different name e.g.
{{org_apache_mesos_authenticator_pam}}, the master will try to load a module
with that name and use its implementation. This is somewhat similar to what
Kapil has done with the Isolator module integration.
2. Make the currently existing authenticator become a module and thereby remove
it from libmesos. Add the {{--authenticators}} flag to the master and ask the
user to supply a module as well ( {{--modules}} ).
3. Mixture of 1. and 2. Difference to 2. would be that we load the
authenticator module implicitly (without the user supplying the {{--modules}}
flag) as soon as he has enabled any kind of authentication (
{{--authenticate_slaves}} / {{--authenticate_frameworks}} ).
was:
There are some options we quickly need to decide upon:
1. Keep the currently existing authenticator (sasl/authenticator.hpp) within
libmesos as a default implementation. Add the --authenticators flag to the
master and if the user selects crammd5, use the linked in, default
implementation. If the user selects a different name e.g.
org_apache_mesos_authenticator_pam, the master will try to load a module with
that name and use its implemenation. This is somewhat similar to what Kapil has
done with the Isolator module integration.
2. Make the currently existing authenticator become a module and thereby remove
it from libmesos. Add the --authenticators flag to the master and ask the user
to supply a module as well (--modules).
3. Mixture of 1. and 2. Difference to 2. would be that we load the
authenticator module implicitly (without the user supplying the --modules flag)
as soon as he has enabled any kind of authentication (--authenticate_slaves /
--authenticate_frameworks).
Integrate the Authenticator module
--
Key: MESOS-1966
URL: https://issues.apache.org/jira/browse/MESOS-1966
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
There are some options we quickly need to decide upon:
1. Keep the currently existing authenticator {{sasl/authenticator.hpp}}
within {{libmesos}} as a default implementation. Add the {{--authenticators}}
flag to the master and if the user selects {{crammd5}}, use the linked in,
default implementation. If the user selects a different name e.g.
{{org_apache_mesos_authenticator_pam}}, the master will try to load a module
with that name and use its implementation. This is somewhat similar to what
Kapil has done with the Isolator module integration.
2. Make the currently existing authenticator become a module and thereby
remove it from libmesos. Add the {{--authenticators}} flag to the master and
ask the user to supply a module as well ( {{--modules}} ).
3. Mixture of 1. and 2. Difference to 2. would be that we load the
authenticator module implicitly (without the user supplying the {{--modules}}
flag) as soon as he has enabled any kind of authentication (
{{--authenticate_slaves}} / {{--authenticate_frameworks}} ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-1889) Create an Authenticator Module
[ https://issues.apache.org/jira/browse/MESOS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1889: -- Description: 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] was: 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] 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 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 (v6.3.4#6332)
[jira] [Commented] (MESOS-1966) Integrate the Authenticator module
[
https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179806#comment-14179806
]
Till Toenshoff commented on MESOS-1966:
---
There are some implications on variant 3 that I think are not perfectly cleared
out yet. Right now, the user has to supply the full path to the module library
(or it has to be part of ldconfig's search path). Did we already decide where
modules are being installed? We would need to make sure that modules are
installed into the standard ldconfig-reachable path for option 3 to work out of
the box, no?
Integrate the Authenticator module
--
Key: MESOS-1966
URL: https://issues.apache.org/jira/browse/MESOS-1966
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
There are some options we quickly need to decide upon:
1. Keep the currently existing authenticator {{sasl/authenticator.hpp}}
within {{libmesos}} as a default implementation. Add the {{--authenticators}}
flag to the master and if the user selects {{crammd5}}, use the linked in,
default implementation. If the user selects a different name e.g.
{{org_apache_mesos_authenticator_pam}}, the master will try to load a module
with that name and use its implementation. This is somewhat similar to what
Kapil has done with the Isolator module integration.
2. Make the currently existing authenticator become a module and thereby
remove it from libmesos. Add the {{--authenticators}} flag to the master and
ask the user to supply a module as well ( {{--modules}} ).
3. Mixture of 1. and 2. Difference to 2. would be that we load the
authenticator module implicitly (without the user supplying the {{--modules}}
flag) as soon as he has enabled any kind of authentication (
{{--authenticate_slaves}} / {{--authenticate_frameworks}} ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1940) Add Mesos-graced/hosted libraries to installation path
[ https://issues.apache.org/jira/browse/MESOS-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180280#comment-14180280 ] Till Toenshoff commented on MESOS-1940: --- Let me try to look at this from the user's perspective who needs to work with the results of this discussion. The trivial use-case up front: supplying a full module library path via --modules certainly is always possible.. The less trivial case would be allowing the user to supply library names without supplying an absolute path. Do we want to cover this case? If so, then there seem to be at least two options: A. Use the configuration-phase prefixed lib-folder (e.g. /usr/local/lib) and rely on ldconfig to initialize that location. B. Use a more specific, mesos-module location (e.g. /usr/local/lib/mesos) and allow mesos to use that location by default (again due to configuration-phase prefixed location) which could then be overridden by a --modules_path flag. Using an ldconfig indexed path certainly makes things rather quick and easy on the integration side. It may however be considered a bit untidy as these modules are very much mesos specific, hence they should not clutter a regular, all-purpose shared object folder. cyrus-sasl2 does use option B with its mechanism plugins. Add Mesos-graced/hosted libraries to installation path -- Key: MESOS-1940 URL: https://issues.apache.org/jira/browse/MESOS-1940 Project: Mesos Issue Type: Task Reporter: Niklas Quarfot Nielsen When more modules are going to show up within the Mesos source base (and even with sample/test modules) it would be convenient to have them be installed alongside the regular Mesos binaries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1543) MasterTest.OrphanTasks is flaky
[
https://issues.apache.org/jira/browse/MESOS-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181394#comment-14181394
]
Till Toenshoff commented on MESOS-1543:
---
I have just seen this one break in a single (unreplicatable) run, unfortunately
I had no logging activated. Do we want to reopen this ticket, or shall I file a
new one?
{noformat}
[ RUN ] MasterTest.OrphanTasks
ABORT: (../../3rdparty/libprocess/3rdparty/stout/include/stout/try.hpp:92):
Try::get() but state == ERROR: Resolver Error 0 (no error)*** Aborted at
1414072736 (unix time) try date -d @1414072736 if you are using GNU date ***
PC: @ 0x7fff9219d282 __pthread_kill
*** SIGABRT (@0x7fff9219d282) received by PID 11348 (TID 0x7fff765a7300) stack
trace: ***
@ 0x7fff94743f1a _sigtramp
@0x1 (unknown)
@ 0x7fff8c40bb73 abort
@0x1048fc0cd _Abort()
@0x1048fc05a _Abort()
@0x104aef8ca mesos::MesosSchedulerDriver::initialize()
@0x104aefc32 mesos::MesosSchedulerDriver::MesosSchedulerDriver()
@0x10349ded9
mesos::internal::tests::TestingMesosSchedulerDriver::TestingMesosSchedulerDriver()
@0x103901314 MasterTest_OrphanTasks_Test::TestBody()
@0x103bf9b1c
testing::internal::HandleExceptionsInMethodIfSupported()
@0x103be4a6a testing::Test::Run()
@0x103be5772 testing::TestInfo::Run()
@0x103be5db0 testing::TestCase::Run()
@0x103beb827 testing::internal::UnitTestImpl::RunAllTests()
@0x103bfa2e4
testing::internal::HandleExceptionsInMethodIfSupported()
@0x103beb539 testing::UnitTest::Run()
@0x103849fa8 main
@ 0x7fff877325c9 start
{noformat}
MasterTest.OrphanTasks is flaky
---
Key: MESOS-1543
URL: https://issues.apache.org/jira/browse/MESOS-1543
Project: Mesos
Issue Type: Bug
Components: test
Reporter: Vinod Kone
Assignee: Yifan Gu
Fix For: 0.20.0
Looks like the slave's detector was discarded before the slave shutdown.
{code}
[ RUN ] MasterTest.OrphanTasks
Using temporary directory '/tmp/MasterTest_OrphanTasks_s8r6NU'
I0625 16:07:58.861265 26203 leveldb.cpp:176] Opened db in 48.741714ms
I0625 16:07:58.877020 26203 leveldb.cpp:183] Compacted db in 15.444957ms
I0625 16:07:58.877488 26203 leveldb.cpp:198] Created db iterator in 8308ns
I0625 16:07:58.877691 26203 leveldb.cpp:204] Seeked to beginning of db in
2133ns
I0625 16:07:58.878000 26203 leveldb.cpp:273] Iterated through 0 keys in the
db in 1896ns
I0625 16:07:58.878221 26203 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I0625 16:07:58.878715 26229 recover.cpp:425] Starting replica recovery
I0625 16:07:58.878783 26229 recover.cpp:451] Replica is in EMPTY status
I0625 16:07:58.879034 26229 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I0625 16:07:58.879088 26229 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I0625 16:07:58.879166 26229 recover.cpp:542] Updating replica status to
STARTING
I0625 16:07:58.882308 26228 master.cpp:288] Master
20140625-160758-16842879-47563-26203 (lucid) started on 127.0.1.1:47563
I0625 16:07:58.882339 26228 master.cpp:325] Master only allowing
authenticated frameworks to register
I0625 16:07:58.882345 26228 master.cpp:330] Master only allowing
authenticated slaves to register
I0625 16:07:58.882351 26228 credentials.hpp:35] Loading credentials for
authentication from '/tmp/MasterTest_OrphanTasks_s8r6NU/credentials'
I0625 16:07:58.882427 26228 master.cpp:356] Authorization enabled
I0625 16:07:58.883036 26228 hierarchical_allocator_process.hpp:301]
Initializing hierarchical allocator process with master :
master@127.0.1.1:47563
I0625 16:07:58.883080 26228 master.cpp:122] No whitelist given. Advertising
offers for all slaves
I0625 16:07:58.883249 26228 master.cpp:1122] The newly elected leader is
master@127.0.1.1:47563 with id 20140625-160758-16842879-47563-26203
I0625 16:07:58.883262 26228 master.cpp:1135] Elected as the leading master!
I0625 16:07:58.883268 26228 master.cpp:953] Recovering from registrar
I0625 16:07:58.883323 26228 registrar.cpp:313] Recovering registrar
I0625 16:07:58.895361 26229 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 16.126207ms
I0625 16:07:58.895427 26229 replica.cpp:320] Persisted replica status to
STARTING
I0625 16:07:58.89 26229 recover.cpp:451] Replica is in STARTING status
I0625 16:07:58.895905 26229 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I0625 16:07:58.895972 26229 recover.cpp:188] Received a recover response from
a replica in STARTING status
I0625 16:07:58.896081 26229 recover.cpp:542]
[jira] [Updated] (MESOS-1927) Enable implicit local cluster launch to load modules
[ https://issues.apache.org/jira/browse/MESOS-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1927: -- Fix Version/s: 0.21.0 Enable implicit local cluster launch to load modules Key: MESOS-1927 URL: https://issues.apache.org/jira/browse/MESOS-1927 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Fix For: 0.21.0 Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1927) Enable implicit local cluster launch to load modules
[ https://issues.apache.org/jira/browse/MESOS-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182062#comment-14182062 ] Till Toenshoff commented on MESOS-1927: --- commit 8bf7e726e59785805f88c67ad1b629bb3dae83d4 Author: Till Toenshoff toensh...@me.com Date: Fri Oct 24 00:00:04 2014 +0200 Added module loading support for local clusters. Frameworks triggering a local cluster (--master=local) now have module loading support via slave and master flags (--modules). Review: https://reviews.apache.org/r/26775 Enable implicit local cluster launch to load modules Key: MESOS-1927 URL: https://issues.apache.org/jira/browse/MESOS-1927 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Fix For: 0.21.0 Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MESOS-1927) Enable implicit local cluster launch to load modules
[ https://issues.apache.org/jira/browse/MESOS-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff resolved MESOS-1927. --- Resolution: Implemented Target Version/s: 0.21.0 Enable implicit local cluster launch to load modules Key: MESOS-1927 URL: https://issues.apache.org/jira/browse/MESOS-1927 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Fix For: 0.21.0 Given that frameworks can launch a local cluster implicitly (for testing purposes), we need to enable local/launch.cpp to load modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MESOS-1990) Unable to build on OS X Yosemite
[
https://issues.apache.org/jira/browse/MESOS-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff closed MESOS-1990.
-
Resolution: Duplicate
You will have to apply https://reviews.apache.org/r/26571 manually to build
mesos 0.20 on yosemite.
Unable to build on OS X Yosemite
Key: MESOS-1990
URL: https://issues.apache.org/jira/browse/MESOS-1990
Project: Mesos
Issue Type: Bug
Components: build
Affects Versions: 0.20.0
Reporter: Gabriel Ki
./include/recordio.h from zookeeper has conflict. Also reported in
ZOOKEEPER-2049.
I got the following errors when I build:
{noformat}
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);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/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 '('
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/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:
./include/recordio.h:76:9: error: conflicting types for '__builtin_constant_p'
int64_t htonll(int64_t v);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h:78:6:
note: expanded from macro '__DARWIN_OSSwapInt64'
(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
^
./include/recordio.h:76:9: note: '__builtin_constant_p' is a builtin with
type 'int ()'
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h:78:6:
note: expanded from macro '__DARWIN_OSSwapInt64'
(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
^
2 errors generated.
{noformat}
My compiler:
{quote}
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1990) Unable to build on OS X Yosemite
[
https://issues.apache.org/jira/browse/MESOS-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182331#comment-14182331
]
Till Toenshoff commented on MESOS-1990:
---
Or as an alternative, use the homebrew version of ZooKeeper as that one has a
fix in place as well.
Unable to build on OS X Yosemite
Key: MESOS-1990
URL: https://issues.apache.org/jira/browse/MESOS-1990
Project: Mesos
Issue Type: Bug
Components: build
Affects Versions: 0.20.0
Reporter: Gabriel Ki
./include/recordio.h from zookeeper has conflict. Also reported in
ZOOKEEPER-2049.
I got the following errors when I build:
{noformat}
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);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/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 '('
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/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:
./include/recordio.h:76:9: error: conflicting types for '__builtin_constant_p'
int64_t htonll(int64_t v);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h:78:6:
note: expanded from macro '__DARWIN_OSSwapInt64'
(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
^
./include/recordio.h:76:9: note: '__builtin_constant_p' is a builtin with
type 'int ()'
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h:141:25:
note: expanded from macro 'htonll'
#define htonll(x) __DARWIN_OSSwapInt64(x)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h:78:6:
note: expanded from macro '__DARWIN_OSSwapInt64'
(__builtin_constant_p(x) ? __DARWIN_OSSwapConstInt64(x) : _OSSwapInt64(x))
^
2 errors generated.
{noformat}
My compiler:
{quote}
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1966) Integrate the Authenticator module
[
https://issues.apache.org/jira/browse/MESOS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184329#comment-14184329
]
Till Toenshoff commented on MESOS-1966:
---
https://reviews.apache.org/r/26859/
Integrate the Authenticator module
--
Key: MESOS-1966
URL: https://issues.apache.org/jira/browse/MESOS-1966
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
There are some options we quickly need to decide upon:
1. Keep the currently existing authenticator {{sasl/authenticator.hpp}}
within {{libmesos}} as a default implementation. Add the {{--authenticators}}
flag to the master and if the user selects {{crammd5}}, use the linked in,
default implementation. If the user selects a different name e.g.
{{org_apache_mesos_authenticator_pam}}, the master will try to load a module
with that name and use its implementation. This is somewhat similar to what
Kapil has done with the Isolator module integration.
2. Make the currently existing authenticator become a module and thereby
remove it from libmesos. Add the {{--authenticators}} flag to the master and
ask the user to supply a module as well ( {{--modules}} ).
3. Mixture of 1. and 2. Difference to 2. would be that we load the
authenticator module implicitly (without the user supplying the {{--modules}}
flag) as soon as he has enabled any kind of authentication (
{{--authenticate_slaves}} / {{--authenticate_frameworks}} ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1894) Authenticator Module: Tests
[
https://issues.apache.org/jira/browse/MESOS-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184330#comment-14184330
]
Till Toenshoff commented on MESOS-1894:
---
Module loadable via mesos-tests parameter {{ --authenticators }}
Authenticator Module: Tests
---
Key: MESOS-1894
URL: https://issues.apache.org/jira/browse/MESOS-1894
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole with some CRAM-MD5 specifics again (
{{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}} {{tests/authentication.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-1998) Subversion include path hardcoding
Till Toenshoff created MESOS-1998:
-
Summary: Subversion include path hardcoding
Key: MESOS-1998
URL: https://issues.apache.org/jira/browse/MESOS-1998
Project: Mesos
Issue Type: Bug
Reporter: Till Toenshoff
Currently, we are using a hardcoded location variant for subversion related
headers. The default path is set to {{/usr/include/subversion-1}}.
This will fail on any OSX homebrew installed version of subversion and may also
fail for other systems.
I would like to suggest changing the current hardcoded path into a basepath and
to reference the actual headers (e.g. svn_delta.h) via
subversion-1/svn_delta.h. This would allow homebrew users (and others) to build
mesos out of the box and without
A. manually supplying the subversion-1 location
B. linking /usr/local/include/subversion-1 towards /usr/include/subversion-1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1998) Subversion include path hardcoding
[
https://issues.apache.org/jira/browse/MESOS-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185692#comment-14185692
]
Till Toenshoff commented on MESOS-1998:
---
That is a good point Timothy, I only checked ubuntu and fedora, both use
subversion-1
Subversion include path hardcoding
--
Key: MESOS-1998
URL: https://issues.apache.org/jira/browse/MESOS-1998
Project: Mesos
Issue Type: Bug
Reporter: Till Toenshoff
Currently, we are using a hardcoded location variant for subversion related
headers. The default path is set to {{/usr/include/subversion-1}}.
This will fail on any OSX homebrew installed version of subversion and may
also fail for other systems.
I would like to suggest changing the current hardcoded path into a basepath
and to reference the actual headers (e.g. svn_delta.h) via
subversion-1/svn_delta.h. This would allow homebrew users (and others) to
build mesos out of the box and without
A. manually supplying the subversion-1 location
B. linking /usr/local/include/subversion-1 towards /usr/include/subversion-1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1951) Add --isolation flag to mesos-tests
[ https://issues.apache.org/jira/browse/MESOS-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185725#comment-14185725 ] Till Toenshoff commented on MESOS-1951: --- commit 1ff259e96396273b36624cf94a7989dee150baa6 Author: Kapil Arya ka...@mesosphere.io Date: Mon Oct 27 21:07:26 2014 +0100 Added --isolation flag for tests. This is useful to test custom isolation modules with the test suite. The user can specify the available modules with --modules and then he can specify the isolator module with the --isolation flag. With these flags, the test suite will run all tests with the specified isolator modules. Review: https://reviews.apache.org/r/26797 Add --isolation flag to mesos-tests --- Key: MESOS-1951 URL: https://issues.apache.org/jira/browse/MESOS-1951 Project: Mesos Issue Type: Documentation Reporter: Niklas Quarfot Nielsen Assignee: Kapil Arya When hooking up specific modules for tests, we realized that it would be generally useful to be able to set the default flags for masters and slaves in the tests. For example let mesos-tests.sh take --isolation, --drf_sorter, --authentication and so on, and have CreateSlaveFlags/CreateMasterFlags alongside necessary ::create() use those flags so we can run the entire unit test suite exercising different implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2001) Authenticatee modules similar to Authenticator modules
Till Toenshoff created MESOS-2001: - Summary: Authenticatee modules similar to Authenticator modules Key: MESOS-2001 URL: https://issues.apache.org/jira/browse/MESOS-2001 Project: Mesos Issue Type: Epic Components: modules Reporter: Till Toenshoff For covering a complete modules based authentication, we will need to allow for authenticatee modules just like we are with authenticator modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2015) Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
Till Toenshoff created MESOS-2015:
-
Summary: Build failure due to unconditional linux/ns.hpp inclusion
in OSX builds
Key: MESOS-2015
URL: https://issues.apache.org/jira/browse/MESOS-2015
Project: Mesos
Issue Type: Bug
Environment: OSX 10.10, clang 3.5
Reporter: Till Toenshoff
{noformat}
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT tests/mesos_tests-credentials_tests.o -MD
-MP -MF tests/.deps/mesos_tests-credentials_tests.Tpo -c -o
tests/mesos_tests-credentials_tests.o `test -f 'tests/credentials_tests.cpp' ||
echo '../../src/'`tests/credentials_tests.cpp
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT
tests/mesos_tests-docker_containerizer_tests.o -MD -MP -MF
tests/.deps/mesos_tests-docker_containerizer_tests.Tpo -c -o
tests/mesos_tests-docker_containerizer_tests.o `test -f
'tests/docker_containerizer_tests.cpp' || echo '../../src/'`
tests/docker_containerizer_tests.cpp
In file included from ../../src/tests/setns_test_helper.cpp:24:
../../src/linux/ns.hpp:20:2: error: linux/ns.hpp is only available on Linux
systems.
#error linux/ns.hpp is only available on Linux systems.
^
In file included from ../../src/tests/setns_test_helper.cpp:24:
In file included from ../../src/linux/ns.hpp:36:
../../3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp:19:2: error:
stout/proc.hpp is only available on Linux systems.
#error stout/proc.hpp is only available on Linux systems.
^
../../3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp:48:11: error:
redefinition of 'proc' as different kind of symbol
namespace proc {
^
/usr/include/sys/proc.h:84:8: note: previous definition is here
struct
[jira] [Commented] (MESOS-2015) Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
[
https://issues.apache.org/jira/browse/MESOS-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190312#comment-14190312
]
Till Toenshoff commented on MESOS-2015:
---
[~idownes] could you please have a look?
Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
---
Key: MESOS-2015
URL: https://issues.apache.org/jira/browse/MESOS-2015
Project: Mesos
Issue Type: Bug
Environment: OSX 10.10, clang 3.5
Reporter: Till Toenshoff
{noformat}
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT tests/mesos_tests-credentials_tests.o -MD
-MP -MF tests/.deps/mesos_tests-credentials_tests.Tpo -c -o
tests/mesos_tests-credentials_tests.o `test -f 'tests/credentials_tests.cpp'
|| echo '../../src/'`tests/credentials_tests.cpp
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT
tests/mesos_tests-docker_containerizer_tests.o -MD -MP -MF
tests/.deps/mesos_tests-docker_containerizer_tests.Tpo -c -o
tests/mesos_tests-docker_containerizer_tests.o `test -f
'tests/docker_containerizer_tests.cpp' || echo '../../src/'`
tests/docker_containerizer_tests.cpp
In file included from ../../src/tests/setns_test_helper.cpp:24:
../../src/linux/ns.hpp:20:2: error: linux/ns.hpp is only available on Linux
systems.
#error linux/ns.hpp is only available on Linux systems.
^
In file included from ../../src/tests/setns_test_helper.cpp:24:
In file included from ../../src/linux/ns.hpp:36:
[jira] [Assigned] (MESOS-2015) Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
[
https://issues.apache.org/jira/browse/MESOS-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff reassigned MESOS-2015:
-
Assignee: Till Toenshoff
Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
---
Key: MESOS-2015
URL: https://issues.apache.org/jira/browse/MESOS-2015
Project: Mesos
Issue Type: Bug
Environment: OSX 10.10, clang 3.5
Reporter: Till Toenshoff
Assignee: Till Toenshoff
{noformat}
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT tests/mesos_tests-credentials_tests.o -MD
-MP -MF tests/.deps/mesos_tests-credentials_tests.Tpo -c -o
tests/mesos_tests-credentials_tests.o `test -f 'tests/credentials_tests.cpp'
|| echo '../../src/'`tests/credentials_tests.cpp
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT
tests/mesos_tests-docker_containerizer_tests.o -MD -MP -MF
tests/.deps/mesos_tests-docker_containerizer_tests.Tpo -c -o
tests/mesos_tests-docker_containerizer_tests.o `test -f
'tests/docker_containerizer_tests.cpp' || echo '../../src/'`
tests/docker_containerizer_tests.cpp
In file included from ../../src/tests/setns_test_helper.cpp:24:
../../src/linux/ns.hpp:20:2: error: linux/ns.hpp is only available on Linux
systems.
#error linux/ns.hpp is only available on Linux systems.
^
In file included from ../../src/tests/setns_test_helper.cpp:24:
In file included from ../../src/linux/ns.hpp:36:
../../3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp:19:2: error:
stout/proc.hpp
[jira] [Comment Edited] (MESOS-2015) Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
[
https://issues.apache.org/jira/browse/MESOS-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190312#comment-14190312
]
Till Toenshoff edited comment on MESOS-2015 at 10/30/14 9:28 PM:
-
[~idownes] could you please have a look?
Actually, was trivial to fix and I took the freedom to do it, please check:
https://reviews.apache.org/r/27395/
was (Author: tillt):
[~idownes] could you please have a look?
Build failure due to unconditional linux/ns.hpp inclusion in OSX builds
---
Key: MESOS-2015
URL: https://issues.apache.org/jira/browse/MESOS-2015
Project: Mesos
Issue Type: Bug
Environment: OSX 10.10, clang 3.5
Reporter: Till Toenshoff
{noformat}
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT tests/mesos_tests-credentials_tests.o -MD
-MP -MF tests/.deps/mesos_tests-credentials_tests.Tpo -c -o
tests/mesos_tests-credentials_tests.o `test -f 'tests/credentials_tests.cpp'
|| echo '../../src/'`tests/credentials_tests.cpp
g++ -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos\ 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-DSOURCE_DIR=\/Users/till/Development/mesos-private/build/..\
-DBUILD_DIR=\/Users/til
l/Development/mesos-private/build\
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/gtest/include
-I../3rdparty/libprocess/3rdparty/gmock-1.6.0/include
-I/usr/include/subversion-1 -I/usr/include/apr-1 -I/usr/include/apr-1.0
-D_THREAD_SAFE -g1 -O0 -std=c++11 -stdlib=libc
++ -DGTEST_USE_OWN_TR1_TUPLE=1 -MT
tests/mesos_tests-docker_containerizer_tests.o -MD -MP -MF
tests/.deps/mesos_tests-docker_containerizer_tests.Tpo -c -o
tests/mesos_tests-docker_containerizer_tests.o `test -f
'tests/docker_containerizer_tests.cpp' || echo '../../src/'`
tests/docker_containerizer_tests.cpp
In file included from ../../src/tests/setns_test_helper.cpp:24:
../../src/linux/ns.hpp:20:2: error: linux/ns.hpp is only available on Linux
systems.
#error
[jira] [Updated] (MESOS-2021) Mesos will not execute on ARM CPU based System
[
https://issues.apache.org/jira/browse/MESOS-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-2021:
--
Summary: Mesos will not execute on ARM CPU based System (was: Mesos will
not execute)
Mesos will not execute on ARM CPU based System
--
Key: MESOS-2021
URL: https://issues.apache.org/jira/browse/MESOS-2021
Project: Mesos
Issue Type: Bug
Components: cli, general
Affects Versions: 0.20.1
Environment: Linux c1-10-1-2-103.cloud.online.net 3.17.0-85 #2 SMP
Wed Oct 15 15:31:27 CEST 2014 armv7l Marvell Armada 370/XP (Device Tree)
GNU/Linux
Reporter: Axel Etcheverry
Priority: Blocker
Configuration : ../configure --disable-java
{noformat}
c1-10-1-2-103 build # ./bin/mesos-master.sh --ip=127.0.0.1
--work_dir=/var/lib/mesos
I1031 12:11:04.993352 21161 main.cpp:155] Build: 2014-10-31 01:04:48 by root
I1031 12:11:04.995046 21161 main.cpp:157] Version: 0.20.1
F1031 12:11:04.997396 21161 leveldb.cpp:160] Check failed:
leveldb::BytewiseComparator()-Compare(one, two) 0
*** Check failure stack trace: ***
@ 0xb63db678 google::LogMessage::Fail()
@ 0xb63dd428 google::LogMessage::SendToLog()
@ 0xb63db294 google::LogMessage::Flush()
@ 0xb63ddbc4 google::LogMessageFatal::~LogMessageFatal()
@ 0xb62c8fb0 mesos::internal::log::LevelDBStorage::restore()
@ 0xb6337198 mesos::internal::log::ReplicaProcess::restore()
@ 0xb6337920 mesos::internal::log::ReplicaProcess::ReplicaProcess()
@ 0xb6337ad4 mesos::internal::log::Replica::Replica()
@ 0xb62ca948 mesos::internal::log::LogProcess::LogProcess()
@ 0xb62cabc8 mesos::internal::log::Log::Log()
@0x41818 main
@ 0xb51965f8 (unknown)
Aborted
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1998) Subversion include path hardcoding
[
https://issues.apache.org/jira/browse/MESOS-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14193265#comment-14193265
]
Till Toenshoff commented on MESOS-1998:
---
Adding results of a compilation attempt to make it easier for users to locate a
solution.
{noformat}
In file included from ../../src/state/log.cpp:25:0:
../../3rdparty/libprocess/3rdparty/stout/include/stout/svn.hpp:21:23: fatal
error: svn_delta.h: No such file or directory
#include svn_delta.h
^
compilation terminated.
make[2]: *** [state/libstate_la-log.lo] Error 1
make[2]: *** Waiting for unfinished jobs
mv -f log/.deps/liblog_la-recover.Tpo log/.deps/liblog_la-recover.Plo
mv -f state/.deps/libstate_la-in_memory.Tpo
state/.deps/libstate_la-in_memory.Plo
libtool: compile: g++-4.9 -DPACKAGE_NAME=\mesos\ -DPACKAGE_TARNAME=\mesos\
-DPACKAGE_VERSION=\0.21.0\ -DPACKAGE_STRING=\mesos 0.21.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\mesos\
-DVERSION=\0.21.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 -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
-D_THREAD_SAFE -g1 -O0 -Wno-unused-local-typedefs -std=c++11
-DGTEST_USE_OWN_TR1_TUPLE=1 -MT state/libstate_la-leveldb.lo -MD -MP -MF
state/.deps/libstate_la-leveldb.Tpo -c ../../src/state/leveldb.cpp -o
state/libstate_la-leveldb.o /dev/null 21
mv -f state/.deps/libstate_la-leveldb.Tpo state/.deps/libstate_la-leveldb.Plo
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
{noformat}
Subversion include path hardcoding
--
Key: MESOS-1998
URL: https://issues.apache.org/jira/browse/MESOS-1998
Project: Mesos
Issue Type: Bug
Reporter: Till Toenshoff
Currently, we are using a hardcoded location variant for subversion related
headers. The default path is set to {{/usr/include/subversion-1}}.
This will fail on any OSX homebrew installed version of subversion and may
also fail for other systems.
I would like to suggest changing the current hardcoded path into a basepath
and to reference the actual headers (e.g. svn_delta.h) via
subversion-1/svn_delta.h. This would allow homebrew users (and others) to
build mesos out of the box and without
A. manually supplying the subversion-1 location
B. linking /usr/local/include/subversion-1 towards /usr/include/subversion-1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2001) Authenticatee modules similar to Authenticator modules
[ https://issues.apache.org/jira/browse/MESOS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14194059#comment-14194059 ] Till Toenshoff commented on MESOS-2001: --- [~adam-mesos] need shepherd :) Authenticatee modules similar to Authenticator modules -- Key: MESOS-2001 URL: https://issues.apache.org/jira/browse/MESOS-2001 Project: Mesos Issue Type: Epic Components: modules Reporter: Till Toenshoff For covering a complete modules based authentication, we will need to allow for authenticatee modules just like we are with authenticator modules. h4.Motivation Allow for third parties to quickly develop and plug-in new authentication methods. The modularized Authenticatee 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2027) make distcheck on OSX 10.10
Till Toenshoff created MESOS-2027:
-
Summary: 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
(v6.3.4#6332)
[jira] [Commented] (MESOS-1981) Create docs/modules.md to record module API changes
[ https://issues.apache.org/jira/browse/MESOS-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195568#comment-14195568 ] Till Toenshoff commented on MESOS-1981: --- Given that Niklas is currently unavailable, I will take the freedom to commit this now. Create docs/modules.md to record module API changes --- Key: MESOS-1981 URL: https://issues.apache.org/jira/browse/MESOS-1981 Project: Mesos Issue Type: Bug Reporter: Kapil Arya Assignee: Kapil Arya The docs/modules.md file keep a history of all module API changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2001) Authenticatee modules similar to Authenticator modules
[ https://issues.apache.org/jira/browse/MESOS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff reassigned MESOS-2001: - Assignee: Till Toenshoff Authenticatee modules similar to Authenticator modules -- Key: MESOS-2001 URL: https://issues.apache.org/jira/browse/MESOS-2001 Project: Mesos Issue Type: Epic Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Labels: authentication, module For covering a complete modules based authentication, we will need to allow for authenticatee modules just like we are with authenticator modules. h4.Motivation Allow for third parties to quickly develop and plug-in new authentication methods. The modularized Authenticatee 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
Till Toenshoff created MESOS-2040: - Summary: Authenticatee Module: Integrate authenticatee module in slave Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Bug Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2041) Authenticatee Module: Integrate authenticatee module in tests
Till Toenshoff created MESOS-2041: - Summary: Authenticatee Module: Integrate authenticatee module in tests Key: MESOS-2041 URL: https://issues.apache.org/jira/browse/MESOS-2041 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Make the authenticatee module testable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
[ https://issues.apache.org/jira/browse/MESOS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-2040: -- Issue Type: Improvement (was: Bug) Authenticatee Module: Integrate authenticatee module in slave - Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2042) Authenticatee Module: Integrate authenticatee module in scheduler
Till Toenshoff created MESOS-2042: - Summary: Authenticatee Module: Integrate authenticatee module in scheduler Key: MESOS-2042 URL: https://issues.apache.org/jira/browse/MESOS-2042 Project: Mesos Issue Type: Improvement Components: modules Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for frameworks to use the authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-830) ExamplesTest.JavaFramework is flaky
[
https://issues.apache.org/jira/browse/MESOS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14196845#comment-14196845
]
Till Toenshoff commented on MESOS-830:
--
I also see this one failing a lot on OSX.
Just ran a gtest_repeat=20 and got 19 failures, 1 pass.
{noformat}
[ RUN ] ExamplesTest.JavaFramework
Using temporary directory '/tmp/ExamplesTest_JavaFramework_DCnIxN'
Enabling authentication for the framework
I1104 22:21:37.416721 112590848 leveldb.cpp:176] Opened db in 2428us
I1104 22:21:37.417207 112590848 leveldb.cpp:183] Compacted db in 454us
I1104 22:21:37.417244 112590848 leveldb.cpp:198] Created db iterator in 15us
I1104 22:21:37.417258 112590848 leveldb.cpp:204] Seeked to beginning of db in
7us
I1104 22:21:37.417268 112590848 leveldb.cpp:273] Iterated through 0 keys in the
db in 8us
I1104 22:21:37.417317 112590848 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 22:21:37.417966 503451648 recover.cpp:437] Starting replica recovery
I1104 22:21:37.418251 503451648 recover.cpp:463] Replica is in EMPTY status
I1104 22:21:37.419044 502378496 replica.cpp:638] Replica in EMPTY status
received a broadcasted recover request
I1104 22:21:37.419242 506134528 recover.cpp:188] Received a recover response
from a replica in EMPTY status
I1104 22:21:37.419445 504524800 recover.cpp:554] Updating replica status to
STARTING
I1104 22:21:37.419777 505597952 leveldb.cpp:306] Persisting metadata (8 bytes)
to leveldb took 231us
I1104 22:21:37.419802 505597952 replica.cpp:320] Persisted replica status to
STARTING
I1104 22:21:37.419909 503988224 recover.cpp:463] Replica is in STARTING status
I1104 22:21:37.420393 502378496 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 22:21:37.420555 503988224 recover.cpp:188] Received a recover response
from a replica in STARTING status
I1104 22:21:37.420811 502915072 recover.cpp:554] Updating replica status to
VOTING
I1104 22:21:37.421128 505597952 leveldb.cpp:306] Persisting metadata (8 bytes)
to leveldb took 193us
I1104 22:21:37.421161 505597952 replica.cpp:320] Persisted replica status to
VOTING
I1104 22:21:37.421190 504524800 recover.cpp:568] Successfully joined the Paxos
group
I1104 22:21:37.421301 504524800 recover.cpp:452] Recover process terminated
I1104 22:21:37.425765 502378496 master.cpp:318] Master
20141104-222137-347252928-55703-8935 (lobomacpro2.fritz.box) started on
192.168.178.20:55703
I1104 22:21:37.425830 502378496 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 22:21:37.425843 502378496 master.cpp:371] Master allowing unauthenticated
slaves to register
I1104 22:21:37.425854 502378496 credentials.hpp:36] Loading credentials for
authentication from '/tmp/ExamplesTest_JavaFramework_DCnIxN/credentials'
W1104 22:21:37.425889 502378496 credentials.hpp:51] Permissions on credentials
file '/tmp/ExamplesTest_JavaFramework_DCnIxN/credentials' are too open. It is
recommended that your credentials file is NOT accessible by others.
I1104 22:21:37.425921 502378496 master.cpp:408] Authorization enabled
I1104 22:21:37.426417 112590848 containerizer.cpp:100] Using isolation:
posix/cpu,posix/mem
I1104 22:21:37.427026 504524800 slave.cpp:169] Slave started on
1)@192.168.178.20:55703
I1104 22:21:37.427248 504524800 slave.cpp:289] Slave resources: cpus(*):2;
mem(*):10240; disk(*):470808; ports(*):[31000-32000]
I1104 22:21:37.427533 112590848 containerizer.cpp:100] Using isolation:
posix/cpu,posix/mem
I1104 22:21:37.428071 503988224 slave.cpp:169] Slave started on
2)@192.168.178.20:55703
I1104 22:21:37.428176 502378496 master.cpp:1258] The newly elected leader is
master@192.168.178.20:55703 with id 20141104-222137-347252928-55703-8935
I1104 22:21:37.428205 502378496 master.cpp:1271] Elected as the leading master!
I1104 22:21:37.428220 502378496 master.cpp:1089] Recovering from registrar
I1104 22:21:37.428267 503988224 slave.cpp:289] Slave resources: cpus(*):2;
mem(*):10240; disk(*):470808; ports(*):[31000-32000]
I1104 22:21:37.428318 502915072 registrar.cpp:313] Recovering registrar
I1104 22:21:37.428598 505061376 log.cpp:656] Attempting to start the writer
I1104 22:21:37.428805 112590848 containerizer.cpp:100] Using isolation:
posix/cpu,posix/mem
I1104 22:21:37.428889 503988224 slave.cpp:318] Slave hostname:
lobomacpro2.fritz.box
I1104 22:21:37.428892 504524800 slave.cpp:318] Slave hostname:
lobomacpro2.fritz.box
I1104 22:21:37.428917 503988224 slave.cpp:319] Slave checkpoint: true
I1104 22:21:37.428927 504524800 slave.cpp:319] Slave checkpoint: true
I1104 22:21:37.429457 506134528 state.cpp:33] Recovering state from
'/var/folders/_t/rdp354gx7j5fjww270kbk6_rgn/T/mesos-XX.3EkfQ7TT/1/meta'
I1104 22:21:37.429478 505061376 state.cpp:33] Recovering state from
'/var/folders/_t/rdp354gx7j5fjww270kbk6_rgn/T/mesos-XX.3EkfQ7TT/0/meta'
[jira] [Commented] (MESOS-1894) Authenticator Module: Tests
[
https://issues.apache.org/jira/browse/MESOS-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198515#comment-14198515
]
Till Toenshoff commented on MESOS-1894:
---
Added an additional step that now does typed testing within the mesos test
suite. That way the CRAMMD5Authentication tests are run against both, the
default (built-in) CRAMMD5Authenticator as well as against the modularized
version of that class.
https://reviews.apache.org/r/27619/
Authenticator Module: Tests
---
Key: MESOS-1894
URL: https://issues.apache.org/jira/browse/MESOS-1894
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
h4. Motivation
Make sure that an authenticator module can be fully unit- and integration-
tested within the mesos test suite.
h4. Status Quo
We currently have a few CRAM-MD5 specific authentication integration tests (
{{tests/sasl_tests.cpp}} ) as well as a complete authentication test list for
authentication as a whole with some CRAM-MD5 specifics again (
{{tests/authentication.cpp}} ).
h4. Approach
1. MESOS-1864 needs to get fleshed out, providing a module integration test
scheme for our mesos test suite
2. refactor / move / rename integration tests of the CRAM-MD5 specific tests
{{tests/sasl_tests.cpp}} {{tests/authentication.cpp}}
3. implement tests via a parameterized version of {{tests/authentication.cpp}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2045) Supply a documentation for the ExternalContainerizer
Till Toenshoff created MESOS-2045: - Summary: Supply a documentation for the ExternalContainerizer Key: MESOS-2045 URL: https://issues.apache.org/jira/browse/MESOS-2045 Project: Mesos Issue Type: Documentation Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Minor The ExternalContainerizer has never been properly documented. That should be fixed even if the Docker use-case has gotten solved for most via the DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2005) Authenticatee Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198609#comment-14198609
]
Till Toenshoff commented on MESOS-2005:
---
https://reviews.apache.org/r/27494/
Authenticatee Module: Interface design
--
Key: MESOS-2005
URL: https://issues.apache.org/jira/browse/MESOS-2005
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
Labels: authentication, interface, module
h4.Motivation
Design an interface covering authenticatee modules while staying minimally
invasive in regards to changes on the existing CRAM-MD5 Authenticatee
implementation.
h4.Status Quo
See MESOS-1891 but replace Authenticator with Authenticatee.
h4.Design
{noformat}
class Authenticatee
{
public:
Authenticatee() {}
virtual ~Authenticatee() {}
virtual TryNothing initialize(
const process::UPID clientPid,
const Optionmesos::Credential credential) = 0;
virtual process::Futurebool authenticate(const process::UPID pid) = 0;
};
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MESOS-2045) Supply a documentation for the ExternalContainerizer
[ https://issues.apache.org/jira/browse/MESOS-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff resolved MESOS-2045. --- Resolution: Implemented commit 0f348c411a301bee4b6af56d0e68120b064d6a2a Author: Till Toenshoff toensh...@me.com Date: Wed Nov 5 17:57:28 2014 +0100 Added External Containerizer documentation. Adds a markdown document describing the ExternalContainerizer. Review: https://reviews.apache.org/r/22169/ Supply a documentation for the ExternalContainerizer Key: MESOS-2045 URL: https://issues.apache.org/jira/browse/MESOS-2045 Project: Mesos Issue Type: Documentation Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Minor The ExternalContainerizer has never been properly documented. That should be fixed even if the Docker use-case has gotten solved for most via the DockerContainerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
[ https://issues.apache.org/jira/browse/MESOS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200083#comment-14200083 ] Till Toenshoff commented on MESOS-2040: --- h4. Request for quick discussion Due to Adam's valuable comment on the above RR, the following issue emerged and needs to be decided upon; The existing logic on enabling a slave to attempt authentication is purely based on the existence of a credential. While that served its purpose, things now become a little odd when adding new authenticatees supporting authentication without credentials (think e.g. ticket based authentication schemes). Seems we got at least two options for enabling the attempt of authentication from the slave side; - add an explicit `--authenticate` flag to the slave - use the new `--authenticatee` selector (introduced by the above RR) and authenticate only if a viable one (non empty?) was given Authenticatee Module: Integrate authenticatee module in slave - Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
[ https://issues.apache.org/jira/browse/MESOS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200085#comment-14200085 ] Till Toenshoff commented on MESOS-2040: --- [~vinodkone] [~adam-mesos] [~benjaminhindman] any thoughts? Authenticatee Module: Integrate authenticatee module in slave - Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
[ https://issues.apache.org/jira/browse/MESOS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200463#comment-14200463 ] Till Toenshoff commented on MESOS-2040: --- I just discussed the issue with BenH and here is what we would like to propose instead: We should stick to the existing way which is to use --credential as a trigger for the slave / framework to attempt authentication (now based on the selected --authenticatee). At least we should do so until someone comes up with an authenticatee module that does not make use of either a principal or a password. This would mean that there was no need for an additional flag (despite --authenticatee), which is good. The reason why this would still work for ticket based authentication mechanisms is that those still use a principal (but no password). Authenticatee Module: Integrate authenticatee module in slave - Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2040) Authenticatee Module: Integrate authenticatee module in slave
[ https://issues.apache.org/jira/browse/MESOS-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200463#comment-14200463 ] Till Toenshoff edited comment on MESOS-2040 at 11/6/14 5:05 PM: I just discussed the issue with BenH and here is what we would like to propose instead: We should stick to the existing way which is to use `-credential as a trigger for the slave / framework to attempt authentication (now based on the selected `-authenticatee`). At least we should do so until someone comes up with an authenticatee module that does not make use of either a principal or a password. This would mean that there was no need for an additional flag (despite `-authenticatee`), which is good. The reason why this would still work for ticket based authentication mechanisms is that those still use a principal (but no password). was (Author: tillt): I just discussed the issue with BenH and here is what we would like to propose instead: We should stick to the existing way which is to use --credential as a trigger for the slave / framework to attempt authentication (now based on the selected --authenticatee). At least we should do so until someone comes up with an authenticatee module that does not make use of either a principal or a password. This would mean that there was no need for an additional flag (despite --authenticatee), which is good. The reason why this would still work for ticket based authentication mechanisms is that those still use a principal (but no password). Authenticatee Module: Integrate authenticatee module in slave - Key: MESOS-2040 URL: https://issues.apache.org/jira/browse/MESOS-2040 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Allow for slave authentication via authenticatee module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2041) Authenticatee Module: Integrate authenticatee module in tests
[ https://issues.apache.org/jira/browse/MESOS-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200921#comment-14200921 ] Till Toenshoff commented on MESOS-2041: --- https://reviews.apache.org/r/27651/ Authenticatee Module: Integrate authenticatee module in tests - Key: MESOS-2041 URL: https://issues.apache.org/jira/browse/MESOS-2041 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Make the authenticatee module testable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2041) Authenticatee Module: Integrate authenticatee module in tests
[ https://issues.apache.org/jira/browse/MESOS-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200921#comment-14200921 ] Till Toenshoff edited comment on MESOS-2041 at 11/6/14 9:07 PM: https://reviews.apache.org/r/27495/ https://reviews.apache.org/r/27651/ was (Author: tillt): https://reviews.apache.org/r/27651/ Authenticatee Module: Integrate authenticatee module in tests - Key: MESOS-2041 URL: https://issues.apache.org/jira/browse/MESOS-2041 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff Assignee: Till Toenshoff Make the authenticatee module testable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2005) Authenticatee Module: Interface design
[
https://issues.apache.org/jira/browse/MESOS-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-2005:
--
Description:
h4.Motivation
Design an interface covering authenticatee modules while staying minimally
invasive in regards to changes on the existing CRAM-MD5 Authenticatee
implementation.
h4.Status Quo
See MESOS-1891 but replace Authenticator with Authenticatee.
h4.Design
{noformat}
class Authenticatee
{
public:
Authenticatee() {}
virtual ~Authenticatee() {}
virtual TryNothing initialize(
const process::UPID clientPid,
const mesos::Credential credential) = 0;
virtual process::Futurebool authenticate(const process::UPID pid) = 0;
};
{noformat}
was:
h4.Motivation
Design an interface covering authenticatee modules while staying minimally
invasive in regards to changes on the existing CRAM-MD5 Authenticatee
implementation.
h4.Status Quo
See MESOS-1891 but replace Authenticator with Authenticatee.
h4.Design
{noformat}
class Authenticatee
{
public:
Authenticatee() {}
virtual ~Authenticatee() {}
virtual TryNothing initialize(
const process::UPID clientPid,
const Optionmesos::Credential credential) = 0;
virtual process::Futurebool authenticate(const process::UPID pid) = 0;
};
{noformat}
Authenticatee Module: Interface design
--
Key: MESOS-2005
URL: https://issues.apache.org/jira/browse/MESOS-2005
Project: Mesos
Issue Type: Improvement
Components: modules
Reporter: Till Toenshoff
Assignee: Till Toenshoff
Priority: Blocker
Labels: authentication, interface, module
h4.Motivation
Design an interface covering authenticatee modules while staying minimally
invasive in regards to changes on the existing CRAM-MD5 Authenticatee
implementation.
h4.Status Quo
See MESOS-1891 but replace Authenticator with Authenticatee.
h4.Design
{noformat}
class Authenticatee
{
public:
Authenticatee() {}
virtual ~Authenticatee() {}
virtual TryNothing initialize(
const process::UPID clientPid,
const mesos::Credential credential) = 0;
virtual process::Futurebool authenticate(const process::UPID pid) = 0;
};
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201770#comment-14201770
]
Till Toenshoff commented on MESOS-2050:
---
Trouble is that modules can not handle static methods. I initially had a
proposal for covering that but it wasn't really scaling well (versioning
issues), hence we decided to drop that approach. I will figure out a solution
that makes everyone happy without pulling something out of the heavy duty mutex
drawer
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378
[jira] [Assigned] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff reassigned MESOS-2050:
-
Assignee: Till Toenshoff
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I1104 03:37:55.537719 28392 leveldb.cpp:343] Persisting action (8 bytes) to
leveldb took 366858ns
I1104
[jira] [Comment Edited] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[ https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14202522#comment-14202522 ] Till Toenshoff edited comment on MESOS-2050 at 11/7/14 7:31 PM: The trigger of this problem indeed most likely is InMemoryAuxiliaryPropertyPlugin::load while InMemoryAuxiliaryPropertyPlugin::lookup. So master triggers a load via CRAMMD5Authenticator::initialize and a CRAMMD5AuthenticatorProcess (which got spawned earlier via CRAMMD5Authenticator::initialize of a different Authenticator instance) tries to lookup concurrently. - bam! So it seems we got several options here; Keep everything as is but... - bandaid: add a mutex onto InMemoryAuxiliaryPropertyPlugin::load / InMemoryAuxiliaryPropertyPlugin::lookup to prevent concurrent access to the underlying data structure (properties) - bandaid: use a process::Once within the CRAMMD5Authenticator::initialize to prevent concurrent and subsequent InMemoryAuxiliaryPropertyPlugin::load... this however will get even uglier as we have tests that want to reload credentials and for those I would have to expose an additional option to reset that process::Once. Revise the Authenticator interface... - proper: instantiate an modularized authenticator factory early on, within master::initialize. That baby does load the credentials. Then, once the master receives the authentication message from slave/framework, it uses that factory to instantiate new authenticator-sessions. This would also make much more sense when we look at authentication mechanisms that might e.g. need to connect to a non-local database (expensive setup). I currently am very much in favor of the last option. But given the extend of changes needed here, I fear that the review delays will be too much for the entire 0.21 release to wait. So unless you vote for a band-aid, I would suggest we revert my Authenticator module commits (both for master and for 0.21), let me implement the proper and depending on when it can get committed, we might still be able to cherry-pick that into 0.21 or it will land in 0.22. These are the commits in question: commit 0756d185ab095d88d7313305417939260067a17f commit 9ca757fc5abf24d9eaa371abcdab2a4ad5449cc3 commit 880ea7da6b5c4c1ac1fcc05f2ad5f5dfc875b94e commit b51f55500b809b452123c011012227d821e02c04 was (Author: tillt): The trigger of this problem indeed most likely is InMemoryAuxiliaryPropertyPlugin::load while InMemoryAuxiliaryPropertyPlugin::lookup. So master triggers a load via CRAMMD5Authenticator::initialize and a CRAMMD5AuthenticatorProcess (which got spawned earlier via CRAMMD5Authenticator::initialize of a different Authenticator instance) tries to lookup concurrently. - bam! So it seems we got several options here; Keep everything as is but... - bandaid: add a mutex onto InMemoryAuxiliaryPropertyPlugin::load / InMemoryAuxiliaryPropertyPlugin::lookup to prevent concurrent access to the underlying data structure (properties) - bandaid: use a process::Once within the CRAMMD5Authenticator::initialize to prevent concurrent and subsequent InMemoryAuxiliaryPropertyPlugin::load... this however will get even uglier as we have tests that want to reload credentials and for those I would have to expose an additional flag. Revise the Authenticator interface... - proper: instantiate an modularized authenticator factory early on, within master::initialize. That baby does load the credentials. Then, once the master receives the authentication message from slave/framework, it uses that factory to instantiate new authenticator-sessions. This would also make much more sense when we look at authentication mechanisms that might e.g. need to connect to a non-local database (expensive setup). I currently am very much in favor of the last option. But given the extend of changes needed here, I fear that the review delays will be too much for the entire 0.21 release to wait. So unless you vote for a band-aid, I would suggest we revert my Authenticator module commits (both for master and for 0.21), let me implement the proper and depending on when it can get committed, we might still be able to cherry-pick that into 0.21 or it will land in 0.22. These are the commits in question: commit 0756d185ab095d88d7313305417939260067a17f commit 9ca757fc5abf24d9eaa371abcdab2a4ad5449cc3 commit 880ea7da6b5c4c1ac1fcc05f2ad5f5dfc875b94e commit b51f55500b809b452123c011012227d821e02c04 InMemoryAuxProp plugin used by Authenticators results in SEGFAULT - Key: MESOS-2050 URL: https://issues.apache.org/jira/browse/MESOS-2050 Project: Mesos Issue Type: Bug Affects Versions: 0.21.0 Reporter: Vinod Kone Assignee: Till Toenshoff Observed this on ASF CI: Basically, as
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203060#comment-14203060
]
Till Toenshoff commented on MESOS-2050:
---
commit ce82e81c12d7f91b158c73465c47725331626f32
Author: Till Toenshoff toensh...@me.com
Date: Sat Nov 8 01:19:50 2014 +0100
Fixed Authenticator SASL auxiliary memory access.
Review: https://reviews.apache.org/r/27741
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill
[jira] [Commented] (MESOS-1118) Add a 'failover' boolean to FrameworkInfo that let's a framework distinguish the failover forever case from setting a very large value for failover_timeout
[ https://issues.apache.org/jira/browse/MESOS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203922#comment-14203922 ] Till Toenshoff commented on MESOS-1118: --- [~ijimenez] are you still working on this one? Add a 'failover' boolean to FrameworkInfo that let's a framework distinguish the failover forever case from setting a very large value for failover_timeout - Key: MESOS-1118 URL: https://issues.apache.org/jira/browse/MESOS-1118 Project: Mesos Issue Type: Improvement Components: framework, master Reporter: Benjamin Hindman Assignee: Isabel Jimenez Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2002) Module loading within frameworks
[ https://issues.apache.org/jira/browse/MESOS-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14204763#comment-14204763 ] Till Toenshoff commented on MESOS-2002: --- https://reviews.apache.org/r/27806/ Module loading within frameworks - Key: MESOS-2002 URL: https://issues.apache.org/jira/browse/MESOS-2002 Project: Mesos Issue Type: Improvement Components: framework, modules Reporter: Till Toenshoff Assignee: Till Toenshoff Priority: Blocker Frameworks should be granted the capability to load modules. h4.Motivation Allowing a modularized Authenticatee to cover framework authentication against the master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2086) Update messages.proto to use a raw bytestream instead of a string for AuthenticationStartMessage.
Till Toenshoff created MESOS-2086:
-
Summary: Update messages.proto to use a raw bytestream instead of
a string for AuthenticationStartMessage.
Key: MESOS-2086
URL: https://issues.apache.org/jira/browse/MESOS-2086
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
{{messages.proto}} has to be slightly changed to use a raw bytestream instead
of a string for {{AuthenticationStartMessage}} as non CRAM-MD5 authentication
mechanisms may transmit binary data.
*NOTE* that the above change does basically have no impact on C++ based proto
code other than the prevention of a warning due to non-UTF8 characters being
encoded.
For more on this subject, please see
https://www.mail-archive.com/protobuf@googlegroups.com/msg01486.html
Even though the above is pretty much determining that we wont run into
compatibility issues (old master vs. new slave and vice versa), it still should
be tested briefly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2086) Update messages.proto to use a raw bytestream instead of a string for AuthenticationStartMessage.
[
https://issues.apache.org/jira/browse/MESOS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207905#comment-14207905
]
Till Toenshoff commented on MESOS-2086:
---
https://reviews.apache.org/r/27494/
Update messages.proto to use a raw bytestream instead of a string for
AuthenticationStartMessage.
-
Key: MESOS-2086
URL: https://issues.apache.org/jira/browse/MESOS-2086
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
{{messages.proto}} has to be slightly changed to use a raw bytestream instead
of a string for {{AuthenticationStartMessage}} as non CRAM-MD5 authentication
mechanisms may transmit binary data.
*NOTE* that the above change does basically have no impact on C++ based proto
code other than the prevention of a warning due to non-UTF8 characters being
encoded.
For more on this subject, please see
https://www.mail-archive.com/protobuf@googlegroups.com/msg01486.html
Even though the above is pretty much determining that we wont run into
compatibility issues (old master vs. new slave and vice versa), it still
should be tested briefly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2086) Update messages.proto to use a raw bytestream instead of a string for AuthenticationStartMessage.
[
https://issues.apache.org/jira/browse/MESOS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207905#comment-14207905
]
Till Toenshoff edited comment on MESOS-2086 at 11/12/14 10:36 AM:
--
https://reviews.apache.org/r/27494/ (change introduced)
https://reviews.apache.org/r/27675/ (change documented)
was (Author: tillt):
https://reviews.apache.org/r/27494/
Update messages.proto to use a raw bytestream instead of a string for
AuthenticationStartMessage.
-
Key: MESOS-2086
URL: https://issues.apache.org/jira/browse/MESOS-2086
Project: Mesos
Issue Type: Improvement
Reporter: Till Toenshoff
Assignee: Till Toenshoff
{{messages.proto}} has to be slightly changed to use a raw bytestream instead
of a string for {{AuthenticationStartMessage}} as non CRAM-MD5 authentication
mechanisms may transmit binary data.
*NOTE* that the above change does basically have no impact on C++ based proto
code other than the prevention of a warning due to non-UTF8 characters being
encoded.
For more on this subject, please see
https://www.mail-archive.com/protobuf@googlegroups.com/msg01486.html
Even though the above is pretty much determining that we wont run into
compatibility issues (old master vs. new slave and vice versa), it still
should be tested briefly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2093) Allow live-updating credential/s on a running master/slave/framework.
Till Toenshoff created MESOS-2093: - Summary: Allow live-updating credential/s on a running master/slave/framework. Key: MESOS-2093 URL: https://issues.apache.org/jira/browse/MESOS-2093 Project: Mesos Issue Type: Improvement Reporter: Till Toenshoff For improving a transition from/to an authenticated slave/framework or changes within principal/s and/or password/s, we would have to permanently watch a given credential/s file and allow the authentication logic to get re-triggered by any changes on these files on both ends (slave/framework and master). There are likely subtasks involved and hence this JIRA might get converted into an EPIC once this improvement should get implemented (if at all). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
