[jira] [Updated] (MESOS-2966) socket::peer() and socket::address() might fail with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2966: -- Target Version/s: 0.23.0 Fix Version/s: (was: 0.23.0) > socket::peer() and socket::address() might fail with SSL enabled > > > Key: MESOS-2966 > URL: https://issues.apache.org/jira/browse/MESOS-2966 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Artem Harutyunyan >Assignee: Joris Van Remoortere > Labels: mesosphere > > libevent SSL currently uses a secondary FD so we need to virtualize the get() > function on socket interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611450#comment-14611450 ] Adam B commented on MESOS-2333: --- Re-resolving, since it was previously Closed:Fixed by the fix for MESOS-2620, but was reopened due to a recent JIRA mishap. > Securing Sandboxes via Filebrowser Access Control > - > > Key: MESOS-2333 > URL: https://issues.apache.org/jira/browse/MESOS-2333 > Project: Mesos > Issue Type: Improvement > Components: security >Reporter: Adam B >Assignee: Alexander Rojas > Labels: authorization, filebrowser, mesosphere, security > > As it stands now, anybody with access to the master or slave web UI can use > the filebrowser to view the contents of any attached/mounted paths on the > master or slave. Currently, the attached paths include master and slave logs > as well as executor/task sandboxes. While there's a chance that the master > and slave logs could contain sensitive information, it's much more likely > that sandboxes could contain customer data or other files that should not be > globally accessible. Securing the sandboxes is the primary goal of this > ticket. > There are four filebrowser endpoints: browse, read, download, and debug. Here > are some potential solutions. > 1) We could easily provide flags that globally enable/disable each endpoint, > allowing coarse-grained "access control". This might be a reasonable > short-term plan. We would also want to update the web UIs to display an > Access Denied error, rather than showing links that open up blank pailers. > 2) Each master and slave handles is own authn/authz. Slaves will need to have > an authenticator, and there must be a way to provide each node with > credentials and ACLs, and keep these in sync across the cluster. > 3) Filter all slave communications through the master(s), which already has > credentials and ACLs. We'll have to restrict access to the filebrowser (and > other?) endpoints to the (leading?) master. Then the master can perform the > authentication and authorization, only passing the request on to the slave if > auth succeeds. > 3a) The slave returns the browse/read/download response back through the > master. This could be a network bottleneck. > 3b) Upon authn/z success, the master redirects the request to the appropriate > slave, which will send the response directly back to the requester. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2226) HookTest.VerifySlaveLaunchExecutorHook is flaky
[
https://issues.apache.org/jira/browse/MESOS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611447#comment-14611447
]
Adam B commented on MESOS-2226:
---
Retargeting out of Mesos 0.23.0, since it is not critical.
> HookTest.VerifySlaveLaunchExecutorHook is flaky
> ---
>
> Key: MESOS-2226
> URL: https://issues.apache.org/jira/browse/MESOS-2226
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.22.0
>Reporter: Vinod Kone
>Assignee: Kapil Arya
> Labels: flaky, flaky-test, mesosphere
>
> Observed this on internal CI
> {code}
> [ RUN ] HookTest.VerifySlaveLaunchExecutorHook
> Using temporary directory '/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME'
> I0114 18:51:34.659353 4720 leveldb.cpp:176] Opened db in 1.255951ms
> I0114 18:51:34.662112 4720 leveldb.cpp:183] Compacted db in 596090ns
> I0114 18:51:34.662364 4720 leveldb.cpp:198] Created db iterator in 177877ns
> I0114 18:51:34.662719 4720 leveldb.cpp:204] Seeked to beginning of db in
> 19709ns
> I0114 18:51:34.663010 4720 leveldb.cpp:273] Iterated through 0 keys in the
> db in 18208ns
> I0114 18:51:34.663312 4720 replica.cpp:744] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0114 18:51:34.664266 4735 recover.cpp:449] Starting replica recovery
> I0114 18:51:34.664908 4735 recover.cpp:475] Replica is in EMPTY status
> I0114 18:51:34.667842 4734 replica.cpp:641] Replica in EMPTY status received
> a broadcasted recover request
> I0114 18:51:34.669117 4735 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I0114 18:51:34.677913 4735 recover.cpp:566] Updating replica status to
> STARTING
> I0114 18:51:34.683157 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 137939ns
> I0114 18:51:34.683507 4735 replica.cpp:323] Persisted replica status to
> STARTING
> I0114 18:51:34.684013 4735 recover.cpp:475] Replica is in STARTING status
> I0114 18:51:34.685554 4738 replica.cpp:641] Replica in STARTING status
> received a broadcasted recover request
> I0114 18:51:34.696512 4736 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I0114 18:51:34.700552 4735 recover.cpp:566] Updating replica status to VOTING
> I0114 18:51:34.701128 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 115624ns
> I0114 18:51:34.701478 4735 replica.cpp:323] Persisted replica status to
> VOTING
> I0114 18:51:34.701817 4735 recover.cpp:580] Successfully joined the Paxos
> group
> I0114 18:51:34.702569 4735 recover.cpp:464] Recover process terminated
> I0114 18:51:34.716439 4736 master.cpp:262] Master
> 20150114-185134-2272962752-57018-4720 (fedora-19) started on
> 192.168.122.135:57018
> I0114 18:51:34.716913 4736 master.cpp:308] Master only allowing
> authenticated frameworks to register
> I0114 18:51:34.717136 4736 master.cpp:313] Master only allowing
> authenticated slaves to register
> I0114 18:51:34.717488 4736 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME/credentials'
> I0114 18:51:34.718077 4736 master.cpp:357] Authorization enabled
> I0114 18:51:34.719238 4738 whitelist_watcher.cpp:65] No whitelist given
> I0114 18:51:34.719755 4737 hierarchical_allocator_process.hpp:285]
> Initialized hierarchical allocator process
> I0114 18:51:34.722584 4736 master.cpp:1219] The newly elected leader is
> master@192.168.122.135:57018 with id 20150114-185134-2272962752-57018-4720
> I0114 18:51:34.722865 4736 master.cpp:1232] Elected as the leading master!
> I0114 18:51:34.723310 4736 master.cpp:1050] Recovering from registrar
> I0114 18:51:34.723760 4734 registrar.cpp:313] Recovering registrar
> I0114 18:51:34.725229 4740 log.cpp:660] Attempting to start the writer
> I0114 18:51:34.727893 4739 replica.cpp:477] Replica received implicit
> promise request with proposal 1
> I0114 18:51:34.728425 4739 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 114781ns
> I0114 18:51:34.728662 4739 replica.cpp:345] Persisted promised to 1
> I0114 18:51:34.731271 4741 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I0114 18:51:34.733223 4734 replica.cpp:378] Replica received explicit
> promise request for position 0 with proposal 2
> I0114 18:51:34.734076 4734 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 87441ns
> I0114 18:51:34.734441 4734 replica.cpp:679] Persisted action at 0
> I0114 18:51:34.740272 4739 replica.cpp:511] Replica received write request
> for position 0
> I0114 18:51:34.740910 4739 leveldb.cpp:438] Reading position from leveldb
> took 59846ns
> I0114 18:51:34.741672 4739 leveldb.cpp:343] Persisting action (14 bytes) t
[jira] [Updated] (MESOS-2226) HookTest.VerifySlaveLaunchExecutorHook is flaky
[
https://issues.apache.org/jira/browse/MESOS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-2226:
--
Target Version/s: 0.24.0 (was: 0.23.0)
> HookTest.VerifySlaveLaunchExecutorHook is flaky
> ---
>
> Key: MESOS-2226
> URL: https://issues.apache.org/jira/browse/MESOS-2226
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.22.0
>Reporter: Vinod Kone
>Assignee: Kapil Arya
> Labels: flaky, flaky-test, mesosphere
>
> Observed this on internal CI
> {code}
> [ RUN ] HookTest.VerifySlaveLaunchExecutorHook
> Using temporary directory '/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME'
> I0114 18:51:34.659353 4720 leveldb.cpp:176] Opened db in 1.255951ms
> I0114 18:51:34.662112 4720 leveldb.cpp:183] Compacted db in 596090ns
> I0114 18:51:34.662364 4720 leveldb.cpp:198] Created db iterator in 177877ns
> I0114 18:51:34.662719 4720 leveldb.cpp:204] Seeked to beginning of db in
> 19709ns
> I0114 18:51:34.663010 4720 leveldb.cpp:273] Iterated through 0 keys in the
> db in 18208ns
> I0114 18:51:34.663312 4720 replica.cpp:744] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0114 18:51:34.664266 4735 recover.cpp:449] Starting replica recovery
> I0114 18:51:34.664908 4735 recover.cpp:475] Replica is in EMPTY status
> I0114 18:51:34.667842 4734 replica.cpp:641] Replica in EMPTY status received
> a broadcasted recover request
> I0114 18:51:34.669117 4735 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I0114 18:51:34.677913 4735 recover.cpp:566] Updating replica status to
> STARTING
> I0114 18:51:34.683157 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 137939ns
> I0114 18:51:34.683507 4735 replica.cpp:323] Persisted replica status to
> STARTING
> I0114 18:51:34.684013 4735 recover.cpp:475] Replica is in STARTING status
> I0114 18:51:34.685554 4738 replica.cpp:641] Replica in STARTING status
> received a broadcasted recover request
> I0114 18:51:34.696512 4736 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I0114 18:51:34.700552 4735 recover.cpp:566] Updating replica status to VOTING
> I0114 18:51:34.701128 4735 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 115624ns
> I0114 18:51:34.701478 4735 replica.cpp:323] Persisted replica status to
> VOTING
> I0114 18:51:34.701817 4735 recover.cpp:580] Successfully joined the Paxos
> group
> I0114 18:51:34.702569 4735 recover.cpp:464] Recover process terminated
> I0114 18:51:34.716439 4736 master.cpp:262] Master
> 20150114-185134-2272962752-57018-4720 (fedora-19) started on
> 192.168.122.135:57018
> I0114 18:51:34.716913 4736 master.cpp:308] Master only allowing
> authenticated frameworks to register
> I0114 18:51:34.717136 4736 master.cpp:313] Master only allowing
> authenticated slaves to register
> I0114 18:51:34.717488 4736 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/HookTest_VerifySlaveLaunchExecutorHook_GjBgME/credentials'
> I0114 18:51:34.718077 4736 master.cpp:357] Authorization enabled
> I0114 18:51:34.719238 4738 whitelist_watcher.cpp:65] No whitelist given
> I0114 18:51:34.719755 4737 hierarchical_allocator_process.hpp:285]
> Initialized hierarchical allocator process
> I0114 18:51:34.722584 4736 master.cpp:1219] The newly elected leader is
> master@192.168.122.135:57018 with id 20150114-185134-2272962752-57018-4720
> I0114 18:51:34.722865 4736 master.cpp:1232] Elected as the leading master!
> I0114 18:51:34.723310 4736 master.cpp:1050] Recovering from registrar
> I0114 18:51:34.723760 4734 registrar.cpp:313] Recovering registrar
> I0114 18:51:34.725229 4740 log.cpp:660] Attempting to start the writer
> I0114 18:51:34.727893 4739 replica.cpp:477] Replica received implicit
> promise request with proposal 1
> I0114 18:51:34.728425 4739 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 114781ns
> I0114 18:51:34.728662 4739 replica.cpp:345] Persisted promised to 1
> I0114 18:51:34.731271 4741 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I0114 18:51:34.733223 4734 replica.cpp:378] Replica received explicit
> promise request for position 0 with proposal 2
> I0114 18:51:34.734076 4734 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 87441ns
> I0114 18:51:34.734441 4734 replica.cpp:679] Persisted action at 0
> I0114 18:51:34.740272 4739 replica.cpp:511] Replica received write request
> for position 0
> I0114 18:51:34.740910 4739 leveldb.cpp:438] Reading position from leveldb
> took 59846ns
> I0114 18:51:34.741672 4739 leveldb.cpp:343] Persisting action (14 bytes) to
> leveldb took 189259ns
> I0114 18:51:34.741919 4739 replica.cpp:679]
[jira] [Comment Edited] (MESOS-2943) mesos fails to compile under mac when libssl and libevent are enabled
[
https://issues.apache.org/jira/browse/MESOS-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611371#comment-14611371
]
Deshi Xiao edited comment on MESOS-2943 at 7/2/15 2:53 AM:
---
I came across same error like report.
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install libevent
Warning: libevent-2.0.22 already installed
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install openssl
Warning: openssl-1.0.2 already installed
was (Author: xds2000):
I came across same error like report.
{{{
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install libevent
Warning: libevent-2.0.22 already installed
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install openssl
Warning: openssl-1.0.2 already installed
}}}
> mesos fails to compile under mac when libssl and libevent are enabled
> -
>
> Key: MESOS-2943
> URL: https://issues.apache.org/jira/browse/MESOS-2943
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Priority: Blocker
> Labels: mesosphere
>
> ../configure --enable-debug --enable-libevent --enable-ssl && make
> produces the following error:
> poll.cpp' || echo '../../../3rdparty/libprocess/'`src/libevent_poll.cpp
> libtool: compile: g++ -DPACKAGE_NAME=\"libprocess\"
> -DPACKAGE_TARNAME=\"libprocess\" -DPACKAGE_VERSION=\"0.0.1\"
> "-DPACKAGE_STRING=\"libprocess 0.0.1\"" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\" -DVERSION=\"0.0.1\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1
> -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
> -DHAVE_LIBCURL=1 -DHAVE_EVENT2_EVENT_H=1 -DHAVE_LIBEVENT=1
> -DHAVE_EVENT2_THREAD_H=1 -DHAVE_LIBEVENT_PTHREADS=1 -DHAVE_OPENSSL_SSL_H=1
> -DHAVE_LIBSSL=1 -DHAVE_LIBCRYPTO=1 -DHAVE_EVENT2_BUFFEREVENT_SSL_H=1
> -DHAVE_LIBEVENT_OPENSSL=1 -DUSE_SSL_SOCKET=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../3rdparty/libprocess -I../../../3rdparty/libprocess/include
> -I../../../3rdparty/libprocess/3rdparty/stout/include -I3rdparty/boost-1.53.0
> -I3rdparty/libev-4.15 -I3rdparty/picojson-4f93734 -I3rdparty/glog-0.3.3/src
> -I3rdparty/ry-http-parser-1c3624a -I/usr/local/opt/openssl/include
> -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -g1 -O0 -std=c++11 -stdlib=libc++
> -DGTEST_USE_OWN_TR1_TUPLE=1 -MT libprocess_la-libevent_poll.lo -MD -MP -MF
> .deps/libprocess_la-libevent_poll.Tpo -c
> ../../../3rdparty/libprocess/src/libevent_poll.cpp -fno-common -DPIC -o
> libprocess_la-libevent_poll.o
> mv -f .deps/libprocess_la-socket.Tpo .deps/libprocess_la-socket.Plo
> mv -f .deps/libprocess_la-subprocess.Tpo .deps/libprocess_la-subprocess.Plo
> mv -f .deps/libprocess_la-libevent.Tpo .deps/libprocess_la-libevent.Plo
> mv -f .deps/libprocess_la-metrics.Tpo .deps/libprocess_la-metrics.Plo
> In file included from
> ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:11:
> In file included from
> ../../../3rdparty/libprocess/include/process/queue.hpp:9:
> ../../../3rdparty/libprocess/include/process/future.hpp:849:7: error: no
> viable conversion from 'const process::Future process::Future >' to 'const
> process::network::Socket'
> set(u);
> ^
> ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:769:10: note: in
> instantiation of function template specialization
> 'process::Future::Future process::Future > >' requested here
> return accept_queue.get()
> ^
> ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate
> constructor (the implicit move constructor) not viable: no known conversion
> from 'const process::Future
> >' to
> 'process::network::Socket &&' for 1st argument
> class Socket
> ^
> ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate
> constructor (the implicit copy constructor) not viable: no known conversion
> from 'const process::Future
> >' to
> 'const process::network::Socket &' for 1st argument
> class Socket
> ^
> ../../../3rdparty/libprocess/include/process/future.hpp:411:21: note: passing
> argument to parameter '_t' here
> bool set(const T& _t);
>^
> 1 error generated.
> make[4]: *** [libprocess_la-libevent_ssl_socket.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> mv -f
[jira] [Commented] (MESOS-2943) mesos fails to compile under mac when libssl and libevent are enabled
[
https://issues.apache.org/jira/browse/MESOS-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611371#comment-14611371
]
Deshi Xiao commented on MESOS-2943:
---
I came across same error like report.
{{{
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install libevent
Warning: libevent-2.0.22 already installed
xiaods at XiaoTommydeMacBook-Pro in ~/Documents/code/mesos/build on master
$ brew install openssl
Warning: openssl-1.0.2 already installed
}}}
> mesos fails to compile under mac when libssl and libevent are enabled
> -
>
> Key: MESOS-2943
> URL: https://issues.apache.org/jira/browse/MESOS-2943
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Priority: Blocker
> Labels: mesosphere
>
> ../configure --enable-debug --enable-libevent --enable-ssl && make
> produces the following error:
> poll.cpp' || echo '../../../3rdparty/libprocess/'`src/libevent_poll.cpp
> libtool: compile: g++ -DPACKAGE_NAME=\"libprocess\"
> -DPACKAGE_TARNAME=\"libprocess\" -DPACKAGE_VERSION=\"0.0.1\"
> "-DPACKAGE_STRING=\"libprocess 0.0.1\"" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\" -DVERSION=\"0.0.1\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1
> -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
> -DHAVE_LIBCURL=1 -DHAVE_EVENT2_EVENT_H=1 -DHAVE_LIBEVENT=1
> -DHAVE_EVENT2_THREAD_H=1 -DHAVE_LIBEVENT_PTHREADS=1 -DHAVE_OPENSSL_SSL_H=1
> -DHAVE_LIBSSL=1 -DHAVE_LIBCRYPTO=1 -DHAVE_EVENT2_BUFFEREVENT_SSL_H=1
> -DHAVE_LIBEVENT_OPENSSL=1 -DUSE_SSL_SOCKET=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
> -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I.
> -I../../../3rdparty/libprocess -I../../../3rdparty/libprocess/include
> -I../../../3rdparty/libprocess/3rdparty/stout/include -I3rdparty/boost-1.53.0
> -I3rdparty/libev-4.15 -I3rdparty/picojson-4f93734 -I3rdparty/glog-0.3.3/src
> -I3rdparty/ry-http-parser-1c3624a -I/usr/local/opt/openssl/include
> -I/usr/local/opt/libevent/include
> -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1
> -I/usr/include/apr-1.0 -g1 -O0 -std=c++11 -stdlib=libc++
> -DGTEST_USE_OWN_TR1_TUPLE=1 -MT libprocess_la-libevent_poll.lo -MD -MP -MF
> .deps/libprocess_la-libevent_poll.Tpo -c
> ../../../3rdparty/libprocess/src/libevent_poll.cpp -fno-common -DPIC -o
> libprocess_la-libevent_poll.o
> mv -f .deps/libprocess_la-socket.Tpo .deps/libprocess_la-socket.Plo
> mv -f .deps/libprocess_la-subprocess.Tpo .deps/libprocess_la-subprocess.Plo
> mv -f .deps/libprocess_la-libevent.Tpo .deps/libprocess_la-libevent.Plo
> mv -f .deps/libprocess_la-metrics.Tpo .deps/libprocess_la-metrics.Plo
> In file included from
> ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:11:
> In file included from
> ../../../3rdparty/libprocess/include/process/queue.hpp:9:
> ../../../3rdparty/libprocess/include/process/future.hpp:849:7: error: no
> viable conversion from 'const process::Future process::Future >' to 'const
> process::network::Socket'
> set(u);
> ^
> ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:769:10: note: in
> instantiation of function template specialization
> 'process::Future::Future process::Future > >' requested here
> return accept_queue.get()
> ^
> ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate
> constructor (the implicit move constructor) not viable: no known conversion
> from 'const process::Future
> >' to
> 'process::network::Socket &&' for 1st argument
> class Socket
> ^
> ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate
> constructor (the implicit copy constructor) not viable: no known conversion
> from 'const process::Future
> >' to
> 'const process::network::Socket &' for 1st argument
> class Socket
> ^
> ../../../3rdparty/libprocess/include/process/future.hpp:411:21: note: passing
> argument to parameter '_t' here
> bool set(const T& _t);
>^
> 1 error generated.
> make[4]: *** [libprocess_la-libevent_ssl_socket.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> mv -f .deps/libprocess_la-libevent_poll.Tpo
> .deps/libprocess_la-libevent_poll.Plo
> mv -f .deps/libprocess_la-openssl.Tpo .deps/libprocess_la-openssl.Plo
> mv -f .deps/libprocess_la-process.Tpo .deps/libprocess_la-process.Plo
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
--
This message was sent
[jira] [Commented] (MESOS-2153) Add support for systemd journal for logging
[ https://issues.apache.org/jira/browse/MESOS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611326#comment-14611326 ] Cody Maloney commented on MESOS-2153: - This should also include individual task stdout/stderr, syslog messages being logged to the systemd journal (although those are more bits of this as an epic). Right now for long-running tasks, the stdout and stderr just grow forever. The systemd journal makes it so the stdout/stderr can be capped size, and administrative policies can be set per app if desired. > Add support for systemd journal for logging > --- > > Key: MESOS-2153 > URL: https://issues.apache.org/jira/browse/MESOS-2153 > Project: Mesos > Issue Type: Improvement > Components: master, slave >Reporter: Alexander Rukletsov >Priority: Minor > > We should be able to redirect master and slave logs to systemd journal on the > systems where it's available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2958) Update Call protobuf to move top level FrameworkInfo inside Subscribe
[ https://issues.apache.org/jira/browse/MESOS-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-2958: -- Sprint: Twitter Mesos Q2 Sprint 6 > Update Call protobuf to move top level FrameworkInfo inside Subscribe > - > > Key: MESOS-2958 > URL: https://issues.apache.org/jira/browse/MESOS-2958 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Vinod Kone > > It is better for FrameworkInfo to be only included in 'Subscribe' message > (that needs to be added) instead of for every call. Instead the top level > Call should contain a FrameworkID to identify the framework making the call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2958) Update Call protobuf to move top level FrameworkInfo inside Subscribe
[ https://issues.apache.org/jira/browse/MESOS-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman updated MESOS-2958: Target Version/s: 0.24.0 (was: 0.23.0) > Update Call protobuf to move top level FrameworkInfo inside Subscribe > - > > Key: MESOS-2958 > URL: https://issues.apache.org/jira/browse/MESOS-2958 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Vinod Kone > > It is better for FrameworkInfo to be only included in 'Subscribe' message > (that needs to be added) instead of for every call. Instead the top level > Call should contain a FrameworkID to identify the framework making the call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2958) Update Call protobuf to move top level FrameworkInfo inside Subscribe
[ https://issues.apache.org/jira/browse/MESOS-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2958: -- Assignee: Vinod Kone > Update Call protobuf to move top level FrameworkInfo inside Subscribe > - > > Key: MESOS-2958 > URL: https://issues.apache.org/jira/browse/MESOS-2958 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone >Assignee: Vinod Kone > > It is better for FrameworkInfo to be only included in 'Subscribe' message > (that needs to be added) instead of for every call. Instead the top level > Call should contain a FrameworkID to identify the framework making the call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2958) Update Call protobuf to move top level FrameworkInfo inside Subscribe
[ https://issues.apache.org/jira/browse/MESOS-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611229#comment-14611229 ] Adam B commented on MESOS-2958: --- Looks like this will be done in https://reviews.apache.org/r/36078 as a part of MESOS-2551 [~vinodkone] Should we close this as a duplicate? I'm at least moving it to Reviewable. > Update Call protobuf to move top level FrameworkInfo inside Subscribe > - > > Key: MESOS-2958 > URL: https://issues.apache.org/jira/browse/MESOS-2958 > Project: Mesos > Issue Type: Improvement >Reporter: Vinod Kone > > It is better for FrameworkInfo to be only included in 'Subscribe' message > (that needs to be added) instead of for every call. Instead the top level > Call should contain a FrameworkID to identify the framework making the call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2982) Make Check Fails on RHEL 6
[ https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611216#comment-14611216 ] Miguel Bernadin commented on MESOS-2982: Thanks again. Yes, here are the test below as requested. I will be able to update the kernel to something more recent. I will do so and provide and update here. MESOS_VERBOSE=1 ./bin/mesos-tests.sh --gtest_filter="SlaveRecoveryTest/0.RecoverSlaveState" Source directory: /usr/local/mesos-0.22.1 Build directory: /usr/local/mesos-0.22.1/build - We cannot run any cgroups tests that require mounting hierarchies because you have the following hierarchies mounted: /cgroup/blkio, /cgroup/cpu, /cgroup/cpuacct, /cgroup/cpuset, /cgroup/devices, /cgroup/freezer, /cgroup/memory, /cgroup/net_cls, /tmp/mesos_test_cgroup/perf_event We'll disable the CgroupsNoHierarchyTest test fixture for now. - Note: Google Test filter = SlaveRecoveryTest/0.RecoverSlaveState-CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy:SlaveCount/Registrar_BENCHMARK_Test.performance/0:SlaveCount/Registrar_BENCHMARK_Test.performance/1:SlaveCount/Registrar_BENCHMARK_Test.performance/2:SlaveCount/Registrar_BENCHMARK_Test.performance/3 [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from SlaveRecoveryTest/0, where TypeParam = mesos::internal::slave::MesosContainerizer ../../src/tests/mesos.cpp:501: Failure (cgroups::cleanup(hierarchy)).failure(): Failed to remove cgroup '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy [ RUN ] SlaveRecoveryTest/0.RecoverSlaveState Using temporary directory '/tmp/SlaveRecoveryTest_0_RecoverSlaveState_InpqgG' ../../src/tests/mesos.cpp:562: Failure cgroups::mount(hierarchy, subsystem): 'freezer' is already attached to another hierarchy - We cannot run any cgroups tests that require a hierarchy with subsystem 'freezer' because we failed to find an existing hierarchy or create a new one (tried '/tmp/mesos_test_cgroup/freezer'). You can either remove all existing hierarchies, or disable this test case (i.e., --gtest_filter=-SlaveRecoveryTest/0.*). - ../../src/tests/mesos.cpp:598: Failure (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam = mesos::internal::slave::MesosContainerizer (7 ms) ../../src/tests/mesos.cpp:519: Failure (cgroups::cleanup(hierarchy)).failure(): Failed to remove cgroup '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy [--] 1 test from SlaveRecoveryTest/0 (7 ms total) [--] Global test environment tear-down [==] 1 test from 1 test case ran. (32 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam = mesos::internal::slave::MesosContainerizer 1 FAILED TEST YOU HAVE 9 DISABLED TESTS > Make Check Fails on RHEL 6 > -- > > Key: MESOS-2982 > URL: https://issues.apache.org/jira/browse/MESOS-2982 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.22.1 > Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 > 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux Server release 6.6 (Santiago) >Reporter: Miguel Bernadin > > After downloading Mesos 22.1 and attemted to build it, I've encountered > failures on the build process below: > FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam > = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) > [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) > [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = > mesos::internal::slave::CgroupsCpushareIsolatorProcess > userdel: user 'mesos.test.unprivileged.user' does not exist > [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup > -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or > directory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2982) Make Check Fails on RHEL 6
[
https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611206#comment-14611206
]
Ian Downes commented on MESOS-2982:
---
It appears all tests that use the MesosContainerizer fail, this definitely
indicates a problem if you want to run with that containerizer.
Could you run one of those failing tests with full verbosity, i.e.,
{{MESOS_VERBOSE=1 ./bin/mesos-tests.sh
--gtest_filter="SlaveRecoveryTest/0.RecoverSlaveState"}}
Lots of things (like namespaces) won't be available on 2.6.32, are you able to
upgrade to a more recent kernel?
> Make Check Fails on RHEL 6
> --
>
> Key: MESOS-2982
> URL: https://issues.apache.org/jira/browse/MESOS-2982
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.22.1
> Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10
> 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
> Red Hat Enterprise Linux Server release 6.6 (Santiago)
>Reporter: Miguel Bernadin
>
> After downloading Mesos 22.1 and attemted to build it, I've encountered
> failures on the build process below:
> FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam
> = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms)
> [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total)
> [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam =
> mesos::internal::slave::CgroupsCpushareIsolatorProcess
> userdel: user 'mesos.test.unprivileged.user' does not exist
> [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
> -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or
> directory
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2982) Make Check Fails on RHEL 6
[ https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611191#comment-14611191 ] Miguel Bernadin commented on MESOS-2982: Thanks a lot Ian! The build seem to have completed and returned these messages below. Do you know if they any of concern? 2015-07-01 16:39:23,342:90964(0x7f33f7fff700):ZOO_ERROR@handle_socket_error_msg@1697: Socket [127.0.0.1:52417] zk retcode=-4, errno=111(Connection refused): server refused to accept the client [ OK ] Strict/RegistrarTest.abort/1 (1021 ms) [--] 16 tests from Strict/RegistrarTest (27443 ms total) [--] Global test environment tear-down [==] 601 tests from 101 test cases ran. (745589 ms total) [ PASSED ] 570 tests. [ FAILED ] 31 tests, listed below: [ FAILED ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf [ FAILED ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.NonCheckpointingSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.KillTask, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.Reboot, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.GCExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileShutdownFramework, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.ReconcileTasksMissingFromSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.SchedulerFailover, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.PartitionedSlave, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MasterFailover, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MultipleFrameworks, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.MultipleSlaves, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] SlaveRecoveryTest/0.RestartBeforeContainerizerLaunch, where TypeParam = mesos::internal::slave::MesosContainerizer [ FAILED ] MesosContainerizerSlaveRecoveryTest.ResourceStatistics [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceForward [ FAILED ] MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceBackward [ FAILED ] ExamplesTest.JavaFramework 31 FAILED TESTS YOU HAVE 9 DISABLED TESTS [root@build]# > Make Check Fails on RHEL 6 > -- > > Key: MESOS-2982 > URL: https://issues.apache.org/jira/browse/MESOS-2982 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.22.1 > Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 > 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux Server release 6.6 (Santiago) >Reporter: Miguel Bernadin > > After downloading Mesos 22.1 and attemted to build it, I've encountered > failures on the build process below: > FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam > = mesos::internal::
[jira] [Commented] (MESOS-2982) Make Check Fails on RHEL 6
[
https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611146#comment-14611146
]
Ian Downes commented on MESOS-2982:
---
Don't repeat the negative "-", i.e.,
{{./bin/mesos-tests.sh
--gtest_filter="-Perf*:UserCgroupIsolatorTest*UserCgroup"}} should work.
See the Google test
[documentation|https://code.google.com/p/googletest/wiki/AdvancedGuide#Running_a_Subset_of_the_Tests],
specifically, "optionally followed by a '-' and another ':'-separated pattern
list (called the negative patterns)", i.e., a single list of patterns.
> Make Check Fails on RHEL 6
> --
>
> Key: MESOS-2982
> URL: https://issues.apache.org/jira/browse/MESOS-2982
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.22.1
> Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10
> 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
> Red Hat Enterprise Linux Server release 6.6 (Santiago)
>Reporter: Miguel Bernadin
>
> After downloading Mesos 22.1 and attemted to build it, I've encountered
> failures on the build process below:
> FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam
> = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms)
> [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total)
> [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam =
> mesos::internal::slave::CgroupsCpushareIsolatorProcess
> userdel: user 'mesos.test.unprivileged.user' does not exist
> [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup
> -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or
> directory
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2982) Make Check Fails on RHEL 6
[ https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miguel Bernadin updated MESOS-2982: --- Description: After downloading Mesos 22.1 and attemted to build it, I've encountered failures on the build process below: FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess userdel: user 'mesos.test.unprivileged.user' does not exist [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or directory was: After downloading Mesos 22.1 and attemted to build it, I've encountered failrues on the build process below: FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess userdel: user 'mesos.test.unprivileged.user' does not exist [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or directory > Make Check Fails on RHEL 6 > -- > > Key: MESOS-2982 > URL: https://issues.apache.org/jira/browse/MESOS-2982 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.22.1 > Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 > 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux Server release 6.6 (Santiago) >Reporter: Miguel Bernadin > > After downloading Mesos 22.1 and attemted to build it, I've encountered > failures on the build process below: > FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam > = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) > [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) > [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = > mesos::internal::slave::CgroupsCpushareIsolatorProcess > userdel: user 'mesos.test.unprivileged.user' does not exist > [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup > -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or > directory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2982) Make Check Fails on RHEL 6
[ https://issues.apache.org/jira/browse/MESOS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611127#comment-14611127 ] Miguel Bernadin commented on MESOS-2982: After reading further, I've attempted to skip this Perf checking process since I've read that Perf is specific to the kernel version and different versions have different flags and output formats. Specifically, the code requires a kernel release >= 2.6.39 but I am running a 2.6.32 kernel: my version of perf is not currently supported and I should skip those tests. The only effect of this is that I cannot use the optional perf_event isolator. That said, I've attempted these commands below to try to skip it but, it seems to ignore my environment variables and flags: build]# GTEST_FILTER="-Perf*:-UserCgroupIsolatorTest*UserCgroup"; export GTEST_FILTER build]# make check GTEST_FILTER="$GTEST_FILTER" That failed above, then I tried this below: build]# ./bin/mesos-tests.sh --gtest_filter="-Perf*:-UserCgroupIsolatorTest*UserCgroup" > Make Check Fails on RHEL 6 > -- > > Key: MESOS-2982 > URL: https://issues.apache.org/jira/browse/MESOS-2982 > Project: Mesos > Issue Type: Bug > Components: build >Affects Versions: 0.22.1 > Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 > 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux Server release 6.6 (Santiago) >Reporter: Miguel Bernadin > > After downloading Mesos 22.1 and attemted to build it, I've encountered > failrues on the build process below: > FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam > = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) > [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) > [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = > mesos::internal::slave::CgroupsCpushareIsolatorProcess > userdel: user 'mesos.test.unprivileged.user' does not exist > [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup > -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or > directory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2982) Make Check Fails on RHEL 6
Miguel Bernadin created MESOS-2982: -- Summary: Make Check Fails on RHEL 6 Key: MESOS-2982 URL: https://issues.apache.org/jira/browse/MESOS-2982 Project: Mesos Issue Type: Bug Components: build Affects Versions: 0.22.1 Environment: Linux xxx 2.6.32-504.16.2.el6.x86_64 #1 SMP Tue Mar 10 17:01:00 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 6.6 (Santiago) Reporter: Miguel Bernadin After downloading Mesos 22.1 and attemted to build it, I've encountered failrues on the build process below: FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms) [--] 1 test from UserCgroupIsolatorTest/0 (149 ms total) [--] 1 test from UserCgroupIsolatorTest/1, where TypeParam = mesos::internal::slave::CgroupsCpushareIsolatorProcess userdel: user 'mesos.test.unprivileged.user' does not exist [ RUN ] UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup -bash: /sys/fs/cgroup/cpuacct/mesos/container/cgroup.procs: No such file or directory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2834) Support different perf output formats
[ https://issues.apache.org/jira/browse/MESOS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611123#comment-14611123 ] Chi Zhang commented on MESOS-2834: -- https://reviews.apache.org/r/36112/ https://reviews.apache.org/r/36113/ https://reviews.apache.org/r/36114/ https://reviews.apache.org/r/36115/ > Support different perf output formats > - > > Key: MESOS-2834 > URL: https://issues.apache.org/jira/browse/MESOS-2834 > Project: Mesos > Issue Type: Improvement > Components: isolation >Reporter: Ian Downes >Assignee: Chi Zhang > Labels: twitter > > The output format of perf changes in 3.14 (inserting an additional field) and > in again in 4.1 (appending additional) fields. See kernel commits: > 410136f5dd96b6013fe6d1011b523b1c247e1ccb > d73515c03c6a2706e088094ff6095a3abefd398b > Update the perf::parse() function to understand all these formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2967) Missing doxygen documentation for libprocess socket interface
[ https://issues.apache.org/jira/browse/MESOS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2967: -- Labels: beginner libprocess mesosphere newbie (was: beginner libprocess newbie) > Missing doxygen documentation for libprocess socket interface > -- > > Key: MESOS-2967 > URL: https://issues.apache.org/jira/browse/MESOS-2967 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Artem Harutyunyan >Assignee: Joseph Wu > Labels: beginner, libprocess, mesosphere, newbie > > Convert existing comments to doxygen format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2967) Missing doxygen documentation for libprocess socket interface
[ https://issues.apache.org/jira/browse/MESOS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Wu reassigned MESOS-2967: Assignee: Joseph Wu > Missing doxygen documentation for libprocess socket interface > -- > > Key: MESOS-2967 > URL: https://issues.apache.org/jira/browse/MESOS-2967 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Artem Harutyunyan >Assignee: Joseph Wu > Labels: beginner, libprocess, newbie > > Convert existing comments to doxygen format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu reassigned MESOS-2965:
Assignee: Joseph Wu
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Assignee: Joseph Wu
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-1865) Redirect to the leader master when current master is not a leader
[
https://issues.apache.org/jira/browse/MESOS-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611005#comment-14611005
]
Cody Maloney commented on MESOS-1865:
-
Following a redirect is entirely a client's choice. Practically in HTTP there
isn't a better alternative I know of that keeps "simple / dumb" clients working
well. Right now a number of dumb client programs which want to pull
master/state.json manually call out to find out what the leading master is from
the master, then going to that directly and hoping there isn't a race around it.
Practically for systems which care to only monitor the exact master they are
talking to, most HTTP libraries I have seen you can disable automatic redirect
following. Currently these APIs sometimes returning incorrect / invalid / stale
data has caused problems for things like proxy config generation scripts (They
get the wrong master at just the wrong point in time and generate an empty
config, leading to badness)
> Redirect to the leader master when current master is not a leader
> -
>
> Key: MESOS-1865
> URL: https://issues.apache.org/jira/browse/MESOS-1865
> Project: Mesos
> Issue Type: Bug
> Components: json api
>Affects Versions: 0.20.1
>Reporter: Steven Schlansker
>Assignee: haosdent
>
> Some of the API endpoints, for example /master/tasks.json, will return bogus
> information if you query a non-leading master:
> {code}
> [steven@Anesthetize:~]% curl
> http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": [
> {
> "executor_id": "",
> "framework_id": "20140724-231003-419644938-5050-1707-",
> "id":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "name":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "resources": {
> "cpus": 0.25,
> "disk": 0,
> {code}
> This is very hard for end-users to work around. For example if I query
> "which master is leading" followed by "leader: which tasks are running" it is
> possible that the leader fails over in between, leaving me with an incorrect
> answer and no way to know that this happened.
> In my opinion the API should return the correct response (by asking the
> current leader?) or an error (500 Not the leader?) but it's unacceptable to
> return a successful wrong answer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610993#comment-14610993
]
Artem Harutyunyan commented on MESOS-2965:
--
Thanks, Ben! We'll make sure to add you as a reviewer for this one :-).
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610980#comment-14610980
]
Benjamin Mahler commented on MESOS-2965:
It seems simpler to have either, or both of:
(1) Implicit casting from Path to string,
(2) Implicit construction of Path from string?
Otherwise, we're likely to end up with a lot of overloads and conversions in
calling code.
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610980#comment-14610980
]
Benjamin Mahler edited comment on MESOS-2965 at 7/1/15 8:49 PM:
It seems simpler to have either, or both of:
(1) Implicit casting from Path to string
(2) Implicit construction of Path from string
Otherwise, we're likely to end up with a lot of overloads and conversions in
calling code.
was (Author: bmahler):
It seems simpler to have either, or both of:
(1) Implicit casting from Path to string,
(2) Implicit construction of Path from string?
Otherwise, we're likely to end up with a lot of overloads and conversions in
calling code.
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2965) Stout os functions don't take Path
[
https://issues.apache.org/jira/browse/MESOS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Harutyunyan updated MESOS-2965:
-
Sprint: Mesosphere Sprint 13
> Stout os functions don't take Path
> ---
>
> Key: MESOS-2965
> URL: https://issues.apache.org/jira/browse/MESOS-2965
> Project: Mesos
> Issue Type: Improvement
> Components: stout
>Reporter: Artem Harutyunyan
>Priority: Minor
> Labels: beginner, mesosphere, newbie, stout
>
> For example:
> {code}inline Try rm(const std::string& path){code} does not have an
> overload for {code}inline Try rm(const Path& path){code}
> The implementation should be something like:
> {code}
> inline Try rm(const Path& path)
> {
> rm(path.value);
> }
> {code}
--
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-tabpanel&focusedCommentId=14610903#comment-14610903
]
Sreeram Boyapati commented on MESOS-1010:
-
I think the issue is fixed. I just made a fresh install after merging with
upstream branch.
> 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 "", line 1, in
> ImportError:
> /home/nekto0n/workspace/mesos/src/python/build/lib.linux-x86_64-2.7/_mesos.so:
> undefined symbol: _ZN6google14FlagRegistererC1EPKcS2_S2_S2_PvS3_
> {noformat}
> Unmangled version of symbol looks like this:
> {noformat}
> google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*,
> char const*, void*, void*)
> {noformat}
> During {{./configure}} step {{glog}} finds {{gflags}} development files and
> starts using them, thus *implicitly* adding dependency on {{libgflags.so}}.
> This breaks Python extensions module and perhaps can break other mesos
> subsystems when moved to hosts without {{gflags}} installed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2981) Allow MesosContainerizer to support modifying launch based on image execution configuration
Timothy Chen created MESOS-2981: --- Summary: Allow MesosContainerizer to support modifying launch based on image execution configuration Key: MESOS-2981 URL: https://issues.apache.org/jira/browse/MESOS-2981 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2980) Support execution configuration to be returned from provisioner
Timothy Chen created MESOS-2980: --- Summary: Support execution configuration to be returned from provisioner Key: MESOS-2980 URL: https://issues.apache.org/jira/browse/MESOS-2980 Project: Mesos Issue Type: Improvement Reporter: Timothy Chen Image specs also includes execution configuration (e.g: Env, user, ports, etc). We should support passing those information from the image provisioner back to the containerizer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1865) Redirect to the leader master when current master is not a leader
[
https://issues.apache.org/jira/browse/MESOS-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610770#comment-14610770
]
Ian Downes commented on MESOS-1865:
---
Sorry for the drive by comment but my 2c is that if you're querying a
*specific* master that is not leading then it should *not* return (through a
redirect) information from the leading master. Yes, it should do something
other than successfully returning empty data but I don't think it should be a
redirect. If you want automatic redirection to the leading master then that
should be done at a higher level.
> Redirect to the leader master when current master is not a leader
> -
>
> Key: MESOS-1865
> URL: https://issues.apache.org/jira/browse/MESOS-1865
> Project: Mesos
> Issue Type: Bug
> Components: json api
>Affects Versions: 0.20.1
>Reporter: Steven Schlansker
>Assignee: haosdent
>
> Some of the API endpoints, for example /master/tasks.json, will return bogus
> information if you query a non-leading master:
> {code}
> [steven@Anesthetize:~]% curl
> http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": [
> {
> "executor_id": "",
> "framework_id": "20140724-231003-419644938-5050-1707-",
> "id":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "name":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "resources": {
> "cpus": 0.25,
> "disk": 0,
> {code}
> This is very hard for end-users to work around. For example if I query
> "which master is leading" followed by "leader: which tasks are running" it is
> possible that the leader fails over in between, leaving me with an incorrect
> answer and no way to know that this happened.
> In my opinion the API should return the correct response (by asking the
> current leader?) or an error (500 Not the leader?) but it's unacceptable to
> return a successful wrong answer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2979) Make container debug information accessible to users
Ian Downes created MESOS-2979:
-
Summary: Make container debug information accessible to users
Key: MESOS-2979
URL: https://issues.apache.org/jira/browse/MESOS-2979
Project: Mesos
Issue Type: Improvement
Components: isolation
Affects Versions: 0.22.1
Reporter: Ian Downes
Currently some useful debug information, namely {{memory.stat}} when killing a
container from an OOM event, is logged to the slave log. This should be logged
to a file somewhere in the container sandbox so users can access it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2978) Provide more debug information when OOMing a container
Ian Downes created MESOS-2978:
-
Summary: Provide more debug information when OOMing a container
Key: MESOS-2978
URL: https://issues.apache.org/jira/browse/MESOS-2978
Project: Mesos
Issue Type: Improvement
Components: isolation
Affects Versions: 0.22.1
Reporter: Ian Downes
Priority: Minor
Currently, the cgroup memory isolator will log the output of {{memory.stat}} if
it detects the container has oom'ed. This information is of some use to see how
different types of memory used contributed to the oom but it does not provide
information about memory usage of specific processes.
We should log process (thread) information, e.g., something to the effect of:
{noformat}
[idownes@foobar]$ pwd
/sys/fs/cgroup/memory/mesos/
[idownes@foobar]$ cat tasks | xargs ps -o pid,tid,stat,time,rss,command -L -p
{noformat}
This output is of variable size (memory.stat is bounded) so measures should be
taken to limit the amount logged.
Note: the oom notification from the kernel is asynchronous with the kernel's
oom handler killing processes and observing the notification is asynchronous in
Mesos. Logging of information is thus best effort and it may lack information
about process(es) that have already been killed by the kernel or even may not
be logged at all if Mesos reacts first to the executor terminating.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2977) Add test case for redirect to the leader master when current master is not a leader.
[ https://issues.apache.org/jira/browse/MESOS-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-2977: Component/s: test > Add test case for redirect to the leader master when current master is not a > leader. > > > Key: MESOS-2977 > URL: https://issues.apache.org/jira/browse/MESOS-2977 > Project: Mesos > Issue Type: Task > Components: test >Reporter: haosdent >Assignee: haosdent >Priority: Minor > > We need add a test case for [MESOS-1865 > |https://issues.apache.org/jira/browse/MESOS-1865] after we allow [MESOS-2976 > start multi masters in test > case|https://issues.apache.org/jira/browse/MESOS-2976]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-2977) Add test case for redirect to the leader master when current master is not a leader.
haosdent created MESOS-2977: --- Summary: Add test case for redirect to the leader master when current master is not a leader. Key: MESOS-2977 URL: https://issues.apache.org/jira/browse/MESOS-2977 Project: Mesos Issue Type: Task Reporter: haosdent Assignee: haosdent Priority: Minor We need add a test case for [MESOS-1865 |https://issues.apache.org/jira/browse/MESOS-1865] after we allow [MESOS-2976 start multi masters in test case|https://issues.apache.org/jira/browse/MESOS-2976]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1865) Redirect to the leader master when current master is not a leader
[
https://issues.apache.org/jira/browse/MESOS-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent updated MESOS-1865:
Summary: Redirect to the leader master when current master is not a leader
(was: Mesos APIs for non-leading masters should return copies of the leader's
state or an error, not a success with incorrect information)
> Redirect to the leader master when current master is not a leader
> -
>
> Key: MESOS-1865
> URL: https://issues.apache.org/jira/browse/MESOS-1865
> Project: Mesos
> Issue Type: Bug
> Components: json api
>Affects Versions: 0.20.1
>Reporter: Steven Schlansker
>Assignee: haosdent
>
> Some of the API endpoints, for example /master/tasks.json, will return bogus
> information if you query a non-leading master:
> {code}
> [steven@Anesthetize:~]% curl
> http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": [
> {
> "executor_id": "",
> "framework_id": "20140724-231003-419644938-5050-1707-",
> "id":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "name":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "resources": {
> "cpus": 0.25,
> "disk": 0,
> {code}
> This is very hard for end-users to work around. For example if I query
> "which master is leading" followed by "leader: which tasks are running" it is
> possible that the leader fails over in between, leaving me with an incorrect
> answer and no way to know that this happened.
> In my opinion the API should return the correct response (by asking the
> current leader?) or an error (500 Not the leader?) but it's unacceptable to
> return a successful wrong answer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-2976) Allow create multi master in test cases
haosdent created MESOS-2976: --- Summary: Allow create multi master in test cases Key: MESOS-2976 URL: https://issues.apache.org/jira/browse/MESOS-2976 Project: Mesos Issue Type: Task Components: libprocess, master, test Reporter: haosdent Assignee: haosdent Priority: Minor Master use "master" as the fixed pid.id. This make it impossible to start multi masters in a same process at the same time. Also, current libprocess only allow bind to one port in one process. In some test scenarios, we need start multi masters at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2374) Support relative host paths for container volumes
[ https://issues.apache.org/jira/browse/MESOS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen updated MESOS-2374: Labels: mesosphere (was: docker) > Support relative host paths for container volumes > - > > Key: MESOS-2374 > URL: https://issues.apache.org/jira/browse/MESOS-2374 > Project: Mesos > Issue Type: Improvement > Components: containerization, docker >Affects Versions: 0.21.1 >Reporter: Mike Babineau >Assignee: Timothy Chen > Labels: mesosphere > Fix For: 0.23.0 > > > There is no convenient way to mount sandbox subdirectories (such as unpacked > archives from fetched URIs) as container volumes. > While it is possible to access sandbox subdirectories via $MESOS_SANDBOX, > this presumes the container is expecting $MESOS_SANDBOX to be passed in. > Furthermore, it also expects the container already knows the resulting > subdirectory paths. Unfortunately, since the archives are extracted by the > fetcher, operators can not control these paths. Path changes to the extracted > archive must be accompanied by a container image change. > One potential solution: > Add support for relative paths to the containerizer. If the containerizer is > given a relative host path, it simply prepends the sandbox path before > passing it to Docker (or similar). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2374) Support relative host paths for container volumes
[ https://issues.apache.org/jira/browse/MESOS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen reassigned MESOS-2374: --- Assignee: Timothy Chen > Support relative host paths for container volumes > - > > Key: MESOS-2374 > URL: https://issues.apache.org/jira/browse/MESOS-2374 > Project: Mesos > Issue Type: Improvement > Components: containerization, docker >Affects Versions: 0.21.1 >Reporter: Mike Babineau >Assignee: Timothy Chen > Labels: mesosphere > Fix For: 0.23.0 > > > There is no convenient way to mount sandbox subdirectories (such as unpacked > archives from fetched URIs) as container volumes. > While it is possible to access sandbox subdirectories via $MESOS_SANDBOX, > this presumes the container is expecting $MESOS_SANDBOX to be passed in. > Furthermore, it also expects the container already knows the resulting > subdirectory paths. Unfortunately, since the archives are extracted by the > fetcher, operators can not control these paths. Path changes to the extracted > archive must be accompanied by a container image change. > One potential solution: > Add support for relative paths to the containerizer. If the containerizer is > given a relative host path, it simply prepends the sandbox path before > passing it to Docker (or similar). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2374) Support relative host paths for container volumes
[ https://issues.apache.org/jira/browse/MESOS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen updated MESOS-2374: Fix Version/s: 0.23.0 > Support relative host paths for container volumes > - > > Key: MESOS-2374 > URL: https://issues.apache.org/jira/browse/MESOS-2374 > Project: Mesos > Issue Type: Improvement > Components: containerization, docker >Affects Versions: 0.21.1 >Reporter: Mike Babineau >Assignee: Timothy Chen > Labels: mesosphere > Fix For: 0.23.0 > > > There is no convenient way to mount sandbox subdirectories (such as unpacked > archives from fetched URIs) as container volumes. > While it is possible to access sandbox subdirectories via $MESOS_SANDBOX, > this presumes the container is expecting $MESOS_SANDBOX to be passed in. > Furthermore, it also expects the container already knows the resulting > subdirectory paths. Unfortunately, since the archives are extracted by the > fetcher, operators can not control these paths. Path changes to the extracted > archive must be accompanied by a container image change. > One potential solution: > Add support for relative paths to the containerizer. If the containerizer is > given a relative host path, it simply prepends the sandbox path before > passing it to Docker (or similar). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2374) Support relative host paths for container volumes
[ https://issues.apache.org/jira/browse/MESOS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Chen updated MESOS-2374: Labels: docker (was: ) > Support relative host paths for container volumes > - > > Key: MESOS-2374 > URL: https://issues.apache.org/jira/browse/MESOS-2374 > Project: Mesos > Issue Type: Improvement > Components: containerization, docker >Affects Versions: 0.21.1 >Reporter: Mike Babineau >Assignee: Timothy Chen > Labels: mesosphere > Fix For: 0.23.0 > > > There is no convenient way to mount sandbox subdirectories (such as unpacked > archives from fetched URIs) as container volumes. > While it is possible to access sandbox subdirectories via $MESOS_SANDBOX, > this presumes the container is expecting $MESOS_SANDBOX to be passed in. > Furthermore, it also expects the container already knows the resulting > subdirectory paths. Unfortunately, since the archives are extracted by the > fetcher, operators can not control these paths. Path changes to the extracted > archive must be accompanied by a container image change. > One potential solution: > Add support for relative paths to the containerizer. If the containerizer is > given a relative host path, it simply prepends the sandbox path before > passing it to Docker (or similar). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2877) Allow libprocess firewall to have more control over the responses sent on failures
[ https://issues.apache.org/jira/browse/MESOS-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2877: -- Fix Version/s: 0.23.0 > Allow libprocess firewall to have more control over the responses sent on > failures > -- > > Key: MESOS-2877 > URL: https://issues.apache.org/jira/browse/MESOS-2877 > Project: Mesos > Issue Type: Bug >Reporter: Alexander Rojas >Assignee: Alexander Rojas > Labels: mesosphere > Fix For: 0.23.0 > > > The libprocess firewall provides a powerful mechanism to control which > requests are accepted based on the pair (socket, request). > However the firewall itself has no control over the responses sent when a > request is rejected beyond a custom message. It always sent a 403 Forbidden > error, however there are cases where the firewall could potentially send > other kind of errors (think 401 Unauthorized if authorization is implemented). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-1865) Mesos APIs for non-leading masters should return copies of the leader's state or an error, not a success with incorrect information
[
https://issues.apache.org/jira/browse/MESOS-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-1865:
--
Shepherd: Adam B
> Mesos APIs for non-leading masters should return copies of the leader's state
> or an error, not a success with incorrect information
> ---
>
> Key: MESOS-1865
> URL: https://issues.apache.org/jira/browse/MESOS-1865
> Project: Mesos
> Issue Type: Bug
> Components: json api
>Affects Versions: 0.20.1
>Reporter: Steven Schlansker
>Assignee: haosdent
>
> Some of the API endpoints, for example /master/tasks.json, will return bogus
> information if you query a non-leading master:
> {code}
> [steven@Anesthetize:~]% curl
> http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": [
> {
> "executor_id": "",
> "framework_id": "20140724-231003-419644938-5050-1707-",
> "id":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "name":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "resources": {
> "cpus": 0.25,
> "disk": 0,
> {code}
> This is very hard for end-users to work around. For example if I query
> "which master is leading" followed by "leader: which tasks are running" it is
> possible that the leader fails over in between, leaving me with an incorrect
> answer and no way to know that this happened.
> In my opinion the API should return the correct response (by asking the
> current leader?) or an error (500 Not the leader?) but it's unacceptable to
> return a successful wrong answer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2721) Architecture document for per-container IP assignment, enforcement and isolation
[ https://issues.apache.org/jira/browse/MESOS-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Arya reassigned MESOS-2721: - Assignee: Kapil Arya > Architecture document for per-container IP assignment, enforcement and > isolation > > > Key: MESOS-2721 > URL: https://issues.apache.org/jira/browse/MESOS-2721 > Project: Mesos > Issue Type: Task >Reporter: Niklas Quarfot Nielsen >Assignee: Kapil Arya > > There are many ways in which we can go around wiring up per-container IPs in > Mesos. > As there are multiple underlying mechanisms and systems for keeping track of > IP pools, we probably need to aim for a very flexible architecture, similar > to the oversubscription project. > There are a couple of folks, companies and vendors interested in getting this > capability into Mesos asap to provide a stronger networking story > (https://www.mail-archive.com/dev@mesos.apache.org/msg32353.html). So let's > start discussing and architecting this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2044) Use one IP address per container for network isolation
[ https://issues.apache.org/jira/browse/MESOS-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Arya reassigned MESOS-2044: - Assignee: Kapil Arya > Use one IP address per container for network isolation > -- > > Key: MESOS-2044 > URL: https://issues.apache.org/jira/browse/MESOS-2044 > Project: Mesos > Issue Type: Epic >Reporter: Cong Wang >Assignee: Kapil Arya > > If there are enough IP addresses, either IPv4 or IPv6, we should use one IP > address per container, instead of the ugly port range based solution. One > problem with this is the IP address management, usually it is managed by a > DHCP server, maybe we need to manage them in mesos master/slave. > Also, maybe use macvlan instead of veth for better isolation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2943) mesos fails to compile under mac when libssl and libevent are enabled
[ https://issues.apache.org/jira/browse/MESOS-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609700#comment-14609700 ] Adam B commented on MESOS-2943: --- Did you install libevent and openssl (with recommended versions) as described in https://github.com/apache/mesos/blob/master/docs/mesos-ssl.md#Dependencies ? > mesos fails to compile under mac when libssl and libevent are enabled > - > > Key: MESOS-2943 > URL: https://issues.apache.org/jira/browse/MESOS-2943 > Project: Mesos > Issue Type: Bug >Reporter: Artem Harutyunyan >Priority: Blocker > Labels: mesosphere > > ../configure --enable-debug --enable-libevent --enable-ssl && make > produces the following error: > poll.cpp' || echo '../../../3rdparty/libprocess/'`src/libevent_poll.cpp > libtool: compile: g++ -DPACKAGE_NAME=\"libprocess\" > -DPACKAGE_TARNAME=\"libprocess\" -DPACKAGE_VERSION=\"0.0.1\" > "-DPACKAGE_STRING=\"libprocess 0.0.1\"" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\" -DVERSION=\"0.0.1\" > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 > -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" > -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_SVN_VERSION_H=1 > -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1 > -DHAVE_LIBCURL=1 -DHAVE_EVENT2_EVENT_H=1 -DHAVE_LIBEVENT=1 > -DHAVE_EVENT2_THREAD_H=1 -DHAVE_LIBEVENT_PTHREADS=1 -DHAVE_OPENSSL_SSL_H=1 > -DHAVE_LIBSSL=1 -DHAVE_LIBCRYPTO=1 -DHAVE_EVENT2_BUFFEREVENT_SSL_H=1 > -DHAVE_LIBEVENT_OPENSSL=1 -DUSE_SSL_SOCKET=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 > -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_LIBDL=1 -I. > -I../../../3rdparty/libprocess -I../../../3rdparty/libprocess/include > -I../../../3rdparty/libprocess/3rdparty/stout/include -I3rdparty/boost-1.53.0 > -I3rdparty/libev-4.15 -I3rdparty/picojson-4f93734 -I3rdparty/glog-0.3.3/src > -I3rdparty/ry-http-parser-1c3624a -I/usr/local/opt/openssl/include > -I/usr/local/opt/libevent/include > -I/usr/local/opt/subversion/include/subversion-1 -I/usr/include/apr-1 > -I/usr/include/apr-1.0 -g1 -O0 -std=c++11 -stdlib=libc++ > -DGTEST_USE_OWN_TR1_TUPLE=1 -MT libprocess_la-libevent_poll.lo -MD -MP -MF > .deps/libprocess_la-libevent_poll.Tpo -c > ../../../3rdparty/libprocess/src/libevent_poll.cpp -fno-common -DPIC -o > libprocess_la-libevent_poll.o > mv -f .deps/libprocess_la-socket.Tpo .deps/libprocess_la-socket.Plo > mv -f .deps/libprocess_la-subprocess.Tpo .deps/libprocess_la-subprocess.Plo > mv -f .deps/libprocess_la-libevent.Tpo .deps/libprocess_la-libevent.Plo > mv -f .deps/libprocess_la-metrics.Tpo .deps/libprocess_la-metrics.Plo > In file included from > ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:11: > In file included from > ../../../3rdparty/libprocess/include/process/queue.hpp:9: > ../../../3rdparty/libprocess/include/process/future.hpp:849:7: error: no > viable conversion from 'const process::Future process::Future >' to 'const > process::network::Socket' > set(u); > ^ > ../../../3rdparty/libprocess/src/libevent_ssl_socket.cpp:769:10: note: in > instantiation of function template specialization > 'process::Future::Future process::Future > >' requested here > return accept_queue.get() > ^ > ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate > constructor (the implicit move constructor) not viable: no known conversion > from 'const process::Future > >' to > 'process::network::Socket &&' for 1st argument > class Socket > ^ > ../../../3rdparty/libprocess/include/process/socket.hpp:21:7: note: candidate > constructor (the implicit copy constructor) not viable: no known conversion > from 'const process::Future > >' to > 'const process::network::Socket &' for 1st argument > class Socket > ^ > ../../../3rdparty/libprocess/include/process/future.hpp:411:21: note: passing > argument to parameter '_t' here > bool set(const T& _t); >^ > 1 error generated. > make[4]: *** [libprocess_la-libevent_ssl_socket.lo] Error 1 > make[4]: *** Waiting for unfinished jobs > mv -f .deps/libprocess_la-libevent_poll.Tpo > .deps/libprocess_la-libevent_poll.Plo > mv -f .deps/libprocess_la-openssl.Tpo .deps/libprocess_la-openssl.Plo > mv -f .deps/libprocess_la-process.Tpo .deps/libprocess_la-process.Plo > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all] Error 2 > make: *** [all-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2962) Slave fails with Abort stacktrace when DNS cannot resolve hostname
[
https://issues.apache.org/jira/browse/MESOS-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609674#comment-14609674
]
Adam B commented on MESOS-2962:
---
bq. If the DNS cannot resolve the hostname-to-IP for a slave node, we correctly
return an Error object, but we then fail with a segfault.
Could you please provide more information on the original error? Can you
include the log/stacktrace?
> Slave fails with Abort stacktrace when DNS cannot resolve hostname
> --
>
> Key: MESOS-2962
> URL: https://issues.apache.org/jira/browse/MESOS-2962
> Project: Mesos
> Issue Type: Bug
> Components: slave
>Affects Versions: 0.22.1
>Reporter: Marco Massenzio
>Assignee: Marco Massenzio
> Labels: tech-debt
>
> If the DNS cannot resolve the hostname-to-IP for a slave node, we correctly
> return an {{Error}} object, but we then fail with a segfault.
> This code adds a more user-friendly message and exits normally (with an
> {{EXIT_FAILURE}} code).
> For example, forcing {{net::getIp()}} to always return an {{Error}}, now
> causes the slave to exit like this:
> {noformat}
> $ ./bin/mesos-slave.sh --master=10.10.1.121:5405
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> E0630 11:31:45.777465 1944417024 process.cpp:899] Could not obtain the IP
> address for stratos.local; the DNS service may not be able to resolve it: >>>
> Marco was here!!!
> $ echo $?
> 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
