[jira] [Updated] (MESOS-3580) Refactor 'protobuf' to accept project function
[
https://issues.apache.org/jira/browse/MESOS-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rukletsov updated MESOS-3580:
---
Shepherd: (was: Alexander Rukletsov)
> Refactor 'protobuf' to accept project function
> --
>
> Key: MESOS-3580
> URL: https://issues.apache.org/jira/browse/MESOS-3580
> Project: Mesos
> Issue Type: Bug
> Components: stout
>Reporter: Klaus Ma
> Labels: refactor, stout
>
> During the code review of MESOS-3405, [~alex-mesos] realized that we use the
> same pattern again and again, for example:
> {code}
> JSON::Array array;
> array.values.reserve(status.network_infos().size()); // MESOS-2353.
> foreach (const NetworkInfo& info, status.network_infos()) {
> array.values.push_back(model(info));
> }
> object.values["network_infos"] = std::move(array);
> {code}
> We cannot use newly added {{JSON::protobuf()}} here, because a different way
> for rendering JSON from protobuf is used. Without digging deep inside, I know
> three ways how we create a JSON out of a proto in our codebase:
> - wrap in {{JSON::Protobuf()}} for individual messages;
> - wrap in one of the model() family functions;
> - pass as it is for built-in types.
> The proposed conversion function covers one of the possible ways. How about
> add one more convertion? Something like:
> {code}
> template
> Array protobuf(const google::protobuf::RepeatedPtrField& repeated,
> const lambda::function(const T&)>& converter)
> {
> static_assert(std::is_convertible::value,
> "T must be a google::protobuf::Message");
> JSON::Array array;
> array.values.reserve(repeated.size());
> foreach (const T& elem, repeated) {
> array.values.push_back(converter(elem));
> }
> return array;
> }
> {code}
> Then the snippet above could be rewritten as:
> {code}
> object.values["network_infos"] =
> std::move(JSON::protobuf(status.network_infos(),
> [](const NetworkInfo& info) { return model(info); });
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3890) Add notion of evictable task to RunTaskMessage
[
https://issues.apache.org/jira/browse/MESOS-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangya Liu reassigned MESOS-3890:
--
Assignee: Guangya Liu (was: Artem Harutyunyan)
> Add notion of evictable task to RunTaskMessage
> --
>
> Key: MESOS-3890
> URL: https://issues.apache.org/jira/browse/MESOS-3890
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Guangya Liu
> Labels: mesosphere
>
> {code}
> message RunTaskMessage {
> ...
> // This list can be non-empty when a task is launched on reserved
> // resources. If the reserved resources are in use (as revocable
> // resources), this list contains the executors that can be evicted
> // to make room to run this task.
> repeated ExecutorID evictable_executors = 5;
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
[
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015549#comment-15015549
]
Bernd Mathiske commented on MESOS-3937:
---
I tried phusion/ubuntu-14.04-amd64. Now I get this:
{noformat}
./bin/mesos-tests.sh
--gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor"
Source directory: /home/vagrant/mesos
Build directory: /home/vagrant/mesos/build
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu, /sys/fs/cgroup/cpuacct,
/sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer,
/sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory, /sys/fs/cgroup/perf_event,
/sys/fs/cgroup/systemd
We'll disable the CgroupsNoHierarchyTest test fixture for now.
...
{noformat}
> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/40AlT8/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master"
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5'
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persistin
[jira] [Commented] (MESOS-3123) DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
[
https://issues.apache.org/jira/browse/MESOS-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015617#comment-15015617
]
Bernd Mathiske commented on MESOS-3123:
---
Alright. I suggest we keep this test disabled in 0.26.0 and keep working on a
fix and/or adding documentation around this issue for 0.27. So we leave the
ticket open.
> DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
> ---
>
> Key: MESOS-3123
> URL: https://issues.apache.org/jira/browse/MESOS-3123
> Project: Mesos
> Issue Type: Bug
> Components: docker, test
>Affects Versions: 0.23.0
> Environment: CentOS 7.1, CentOS 6.6, or Ubuntu 14.04
> Mesos 0.23.0-rc4 or today's master
> Docker 1.9
>Reporter: Adam B
>Assignee: Timothy Chen
> Labels: mesosphere
>
> Fails the test and then crashes while trying to shutdown the slaves.
> {code}
> [ RUN ] DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged
> ../../src/tests/docker_containerizer_tests.cpp:618: Failure
> Value of: statusRunning.get().state()
> Actual: TASK_LOST
> Expected: TASK_RUNNING
> ../../src/tests/docker_containerizer_tests.cpp:619: Failure
> Failed to wait 1mins for statusFinished
> ../../src/tests/docker_containerizer_tests.cpp:610: Failure
> Actual function call count doesn't match EXPECT_CALL(sched,
> statusUpdate(&driver, _))...
> Expected: to be called twice
>Actual: called once - unsatisfied and active
> F0721 21:59:54.950773 30622 logging.cpp:57] RAW: Pure virtual method called
> @ 0x7f3915347a02 google::LogMessage::Fail()
> @ 0x7f391534cee4 google::RawLog__()
> @ 0x7f3914890312 __cxa_pure_virtual
> @ 0x88c3ae mesos::internal::tests::Cluster::Slaves::shutdown()
> @ 0x88c176 mesos::internal::tests::Cluster::Slaves::~Slaves()
> @ 0x88dc16 mesos::internal::tests::Cluster::~Cluster()
> @ 0x88dc87 mesos::internal::tests::MesosTest::~MesosTest()
> @ 0xa529ab
> mesos::internal::tests::DockerContainerizerTest::~DockerContainerizerTest()
> @ 0xa8125f
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @ 0xa8128e
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @ 0x1218b4e testing::Test::DeleteSelf_()
> @ 0x1221909
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x121cb38
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x1205713 testing::TestInfo::Run()
> @ 0x1205c4e testing::TestCase::Run()
> @ 0x120a9ca testing::internal::UnitTestImpl::RunAllTests()
> @ 0x122277b
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x121d81b
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x120987a testing::UnitTest::Run()
> @ 0xcfbf0c main
> @ 0x7f391097caf5 __libc_start_main
> @ 0x882089 (unknown)
> make[3]: *** [check-local] Aborted (core dumped)
> make[3]: Leaving directory `/home/me/mesos/build/src'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/home/me/mesos/build/src'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory `/home/me/mesos/build/src'
> make: *** [check-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
[
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-3937:
--
Assignee: Timothy Chen
> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/40AlT8/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master"
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5'
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a
> I1117 15:08:09.296115 26399 master.cpp:1619] Elected as the leading master!
> I1117 15:08:09.296187 26399 master.cpp:1379] Recovering fro
[jira] [Updated] (MESOS-3949) User CGroup Isolation tests fail on Centos 6.
[
https://issues.apache.org/jira/browse/MESOS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Mathiske updated MESOS-3949:
--
Assignee: Joris Van Remoortere
> User CGroup Isolation tests fail on Centos 6.
> -
>
> Key: MESOS-3949
> URL: https://issues.apache.org/jira/browse/MESOS-3949
> Project: Mesos
> Issue Type: Bug
> Components: isolation
>Affects Versions: 0.26.0
> Environment: CentOS 6.6, gcc 4.8.1, on vagrant libvirt, 16GB, 8 CPUs,
> ../configure --enable-libevent --enable-ssl
>Reporter: Bernd Mathiske
>Assignee: Joris Van Remoortere
> Labels: mesosphere
>
> UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup and
> UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup fail on CentOS 6.6 with
> similar output when libevent and SSL are enabled.
> {noformat}
> sudo ./bin/mesos-tests.sh
> --gtest_filter="UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from UserCgroupIsolatorTest/0, where TypeParam =
> mesos::internal::slave::CgroupsMemIsolatorProcess
> userdel: user 'mesos.test.unprivileged.user' does not exist
> [ RUN ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
> I1118 16:53:35.273717 30249 mem.cpp:605] Started listening for OOM events for
> container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.274538 30249 mem.cpp:725] Started listening on low memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.275164 30249 mem.cpp:725] Started listening on medium memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.275784 30249 mem.cpp:725] Started listening on critical memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.276448 30249 mem.cpp:356] Updated 'memory.soft_limit_in_bytes'
> to 1GB for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.277331 30249 mem.cpp:391] Updated 'memory.limit_in_bytes' to
> 1GB for container 867a829e-4a26-43f5-86e0-938bf1f47688
> -bash:
> /sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/cgroup.procs:
> No such file or directory
> mkdir: cannot create directory
> `/sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/user': No
> such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1307: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'mkdir " +
> path::join(flags.cgroups_hierarchy, userCgroup) + "'")
> Actual: 256
> Expected: 0
> -bash:
> /sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/user/cgroup.procs:
> No such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1316: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'echo $$ >" +
> path::join(flags.cgroups_hierarchy, userCgroup, "cgroup.procs") + "'")
> Actual: 256
> Expected: 0
> [ FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms)
> {noformat}
> {noformat}
> sudo ./bin/mesos-tests.sh
> --gtest_filter="UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 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
> I1118 17:01:00.550706 30357 cpushare.cpp:392] Updated 'cpu.shares' to 1024
> (cpus 1) for container e57f4343-1a97-4b44-b347-803be47ace80
> -bash:
> /sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/cgroup.procs:
> No such file or directory
> mkdir: cannot create directory
> `/sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/user': No
> such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1307: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'mkdir " +
> path::join(flags.cgroups_hierarchy, userCgroup) + "'")
> Actual: 256
> Expected: 0
> -bash:
> /sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/user/cgroup.procs:
> No such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1316: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'echo $$ >" +
> path::join(flags.cgroups_hierarchy, userCgroup, "cgroup.procs") + "'")
> Actual: 256
> Expected: 0
> -bash:
> /sys/fs/cgroup/cpu/mesos/e57f4343-1a97-4b44-b347-803be47ace80/cgroup.procs:
> No such file or directory
> mkdir: cannot create directory
> `/sys/fs/cg
[jira] [Created] (MESOS-3964) LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.
Bernd Mathiske created MESOS-3964:
-
Summary: LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and
LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.
Key: MESOS-3964
URL: https://issues.apache.org/jira/browse/MESOS-3964
Project: Mesos
Issue Type: Bug
Components: isolation, test
Affects Versions: 0.26.0
Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
Vagrantfile: see MESOS-3957
Reporter: Bernd Mathiske
Assignee: Greg Mann
sudo ./bin/mesos-test.sh
--gtest_filter="LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs"
{noformat}
...
F1119 14:34:52.514742 30706 isolator_tests.cpp:455] CHECK_SOME(isolator):
Failed to find 'cpu.cfs_quota_us'. Your kernel might be too old to use the CFS
cgroups feature.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3965) Ensure resources in `QuotaInfo` protobuf do not contain `role`
Alexander Rukletsov created MESOS-3965:
--
Summary: Ensure resources in `QuotaInfo` protobuf do not contain
`role`
Key: MESOS-3965
URL: https://issues.apache.org/jira/browse/MESOS-3965
Project: Mesos
Issue Type: Bug
Components: master
Reporter: Alexander Rukletsov
Assignee: Alexander Rukletsov
{{QuotaInfo}} protobuf currently stores per-role quotas, including {{Resource}}
objects. These resources are neither statically nor dynamically reserved, hence
they may not contain {{role}} field. We should ensure this field is unset, as
well as update validation routine for {{QuotaInfo}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1
Till Toenshoff created MESOS-3966:
-
Summary:
LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on
Centos 7.1
Key: MESOS-3966
URL: https://issues.apache.org/jira/browse/MESOS-3966
Project: Mesos
Issue Type: Bug
Affects Versions: 0.26.0
Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
Reporter: Till Toenshoff
Assignee: Joris Van Remoortere
{noformat}
[ RUN ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
I1120 11:39:37.862926 29944 linux.cpp:82] Making
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
a shared mount
I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using
/sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality `Delegate`
was introduced in Version `218`. Your system may not function properly; however
since some distributions have patched systemd packages, your system may still
be functional. This is why we keep running. See MESOS-3352 for more information
I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice
`mesos_executors.slice`
I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container
'1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of
framework ''
I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
Failed to wait 15secs for launch
[ FAILED ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
(55076 ms)
[--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
{noformat}
The following vagrant generator was used:
{noformat}
cat << EOF > Vagrantfile
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# Disable shared folder to prevent certain kernel module dependencies.
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.hostname = "centos71"
config.vm.box = "bento/centos-7.1"
config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
end
config.vm.provider "vmware_fusion" do |vb|
vb.memory = 9216
vb.cpus = 4
end
config.vm.provision "shell", inline: <<-SHELL
sudo yum -y update systemd
sudo yum install -y tar wget
sudo wget
http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo
-O /etc/yum.repos.d/epel-apache-maven.repo
sudo yum groupinstall -y "Development Tools"
sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel
zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5
apr-devel subversion-devel apr-util-devel
sudo yum install -y git
sudo yum install -y docker
sudo service docker start
sudo docker info
#sudo wget -qO- https://get.docker.com/ | sh
SHELL
end
EOF
vagrant up
vagrant reload
vagrant ssh -c "
git clone https://github.com/apache/mesos.git mesos
cd mesos
git checkout -b 0.26.0-rc1 0.26.0-rc1
./bootstrap
mkdir build
cd build
../configure
make -j4 check
#make -j4 distcheck
sudo ./bin/mesos-tests.sh
#make clean
#../configure --enable-libevent --enable-ssl
#GTEST_FILTER="" make check
#sudo ./bin/mesos-tests.sh
"
{noformat}
Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing a
pass of the bridged docker executor tests).
{noformat}
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.218.135 centos71
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3967) Add integration tests for quota
Alexander Rukletsov created MESOS-3967: -- Summary: Add integration tests for quota Key: MESOS-3967 URL: https://issues.apache.org/jira/browse/MESOS-3967 Project: Mesos Issue Type: Task Components: allocation, master, test Reporter: Alexander Rukletsov Assignee: Alexander Rukletsov These tests should verify whether quota implements declared functionality. This will require the whole pipeline: master harness code and an allocator implementation (in contrast to to isolated master and allocator tests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1
[
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15016424#comment-15016424
]
Till Toenshoff commented on MESOS-3966:
---
After doing a kernel update to "kernel.x86_64 0:3.10.0-229.20.1.el7" via {{sudo
yum update}} and reloading the VM, the problem manifested slightly different
but still the test fails;
{noformat}
[ RUN ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
I1120 11:52:54.555380 12412 linux.cpp:82] Making
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_40kLiI'
a shared mount
I1120 11:52:54.571110 12412 linux_launcher.cpp:103] Using
/sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
I1120 11:52:54.578615 12412 systemd.cpp:128] systemd version `208` detected
W1120 11:52:54.578649 12412 systemd.cpp:136] Required functionality `Delegate`
was introduced in Version `218`. Your system may not function properly; however
since some distributions have patched systemd packages, your system may still
be functional. This is why we keep running. See MESOS-3352 for more information
I1120 11:52:54.579174 12412 systemd.cpp:189] Created systemd slice:
`/run/systemd/system/mesos_executors.slice`
I1120 11:52:54.649775 12412 systemd.cpp:210] Started systemd slice
`mesos_executors.slice`
I1120 11:52:54.652878 12429 containerizer.cpp:618] Starting container
'02d25ea9-5b29-47a8-80f1-d5de569b3bba' for executor 'test_executor' of
framework ''
I1120 11:52:54.657270 12433 provisioner.cpp:289] Provisioning image rootfs
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_40kLiI/provisioner/containers/02d25ea9-5b29-47a8-80f1-d5de569b3bba/backends/copy/rootfses/704aa4f7-f9dd-4ddc-bf03-8a88aa1dff4d'
for container 02d25ea9-5b29-47a8-80f1-d5de569b3bba
I1120 11:53:03.168793 12427 provisioner.cpp:289] Provisioning image rootfs
'/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_40kLiI/provisioner/containers/02d25ea9-5b29-47a8-80f1-d5de569b3bba/backends/copy/rootfses/7a220702-baa1-4368-a723-7d638c76364f'
for container 02d25ea9-5b29-47a8-80f1-d5de569b3bba
../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
Failed to wait 15secs for launch
F1120 11:53:10.446797 12429 linux.cpp:358] Check failed:
infos.contains(containerId)
*** Check failure stack trace: ***
@ 0x7f36db6faafe google::LogMessage::Fail()
@ 0x7f36db6faa5d google::LogMessage::SendToLog()
@ 0x7f36db6fa46e google::LogMessage::Flush()
@ 0x7f36db6fd1a2 google::LogMessageFatal::~LogMessageFatal()
@ 0x7f36db1f9035
mesos::internal::slave::LinuxFilesystemIsolatorProcess::__prepare()
@ 0x7f36db1f89a8
_ZZN5mesos8internal5slave30LinuxFilesystemIsolatorProcess8_prepareERKNS_11ContainerIDERKNS_12ExecutorInfoERKSsRK6OptionISsESE_ENKUlvE0_clEv
@ 0x7f36db1fe604
_ZNSt17_Function_handlerIFN7process6FutureI6OptionIN5mesos5slave20ContainerPrepareInfovEZNS3_8internal5slave30LinuxFilesystemIsolatorProcess8_prepareERKNS3_11ContainerIDERKNS3_12ExecutorInfoERKSsRKS2_ISsESM_EUlvE0_E9_M_invokeERKSt9_Any_data
@ 0x7f36daf9731f std::function<>::operator()()
@ 0x7f36db20b353
_ZNSt5_BindIFSt8functionIFN7process6FutureI6OptionIN5mesos5slave20ContainerPrepareInfovEEvEE6__callIS8_JRKSt4listI7NothingSaISF_EEEJEEET_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
@ 0x7f36db20a841 std::_Bind<>::operator()<>()
@ 0x7f36db2094ac std::_Function_handler<>::_M_invoke()
@ 0x7f36db20bb55 std::function<>::operator()()
@ 0x7f36db20b3e7 process::internal::thenf<>()
@ 0x7f36db20c4c1
_ZNSt5_BindIFPFvRKSt8functionIFN7process6FutureI6OptionIN5mesos5slave20ContainerPrepareInfoRKSt4listI7NothingSaISA_RKSt10shared_ptrINS1_7PromiseIS7_EEERKNS2_ISC_EEESG_SM_St12_PlaceholderILi16__callIvISR_EILm0ELm1ELm2T_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
@ 0x7f36db20c08b std::_Bind<>::operator()<>()
@ 0x7f36db20bdec std::_Function_handler<>::_M_invoke()
@ 0xba28eb std::function<>::operator()()
@ 0x7f36dadda697
_ZZNK7process6FutureISt4listI7NothingSaIS2_EEE5onAnyIRSt8functionIFvRKS5_EEvEES9_OT_NS5_6PreferEENUlS9_E_clES9_
@ 0x7f36dade7310
_ZNSt17_Function_handlerIFvRKN7process6FutureISt4listI7NothingSaIS3_EZNKS6_5onAnyIRSt8functionIS9_EvEES8_OT_NS6_6PreferEEUlS8_E_E9_M_invokeERKSt9_Any_dataS8_
@ 0xba28eb std::function<>::operator()()
@ 0xb9e979
_ZN7process8internal3runISt8functionIFvRKNS_6FutureISt4listI7NothingSaIS5_EEJRS8_EEEvRKSt6vectorIT_SaISF_EEDpOT0_
@ 0xb999db process::Future<>::set()
@ 0xbae714 process::Promise<>::set()
@ 0xbacf3c process::internal::CollectProcess<>::waited()
@ 0xbafd1f
_ZZN7process8dispatchINS_8internal14CollectProcessI7NothingEERKNS_6Future
[jira] [Commented] (MESOS-3966) LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on Centos 7.1
[
https://issues.apache.org/jira/browse/MESOS-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15016728#comment-15016728
]
Till Toenshoff commented on MESOS-3966:
---
After doing an additional docker update! to 1.9 with its selinux dependencies
via {{wget -qO- https://get.docker.com/ | sh}} the problem disappeared and I
was able to get by this test.
> LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem fails on
> Centos 7.1
>
>
> Key: MESOS-3966
> URL: https://issues.apache.org/jira/browse/MESOS-3966
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: centos 7.1, gcc 4.8.3, docker 1.8.2
>Reporter: Till Toenshoff
>Assignee: Joris Van Remoortere
>
> {noformat}
> [ RUN ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> I1120 11:39:37.862926 29944 linux.cpp:82] Making
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E'
> a shared mount
> I1120 11:39:37.876965 29944 linux_launcher.cpp:103] Using
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> I1120 11:39:37.930881 29944 systemd.cpp:128] systemd version `208` detected
> W1120 11:39:37.930913 29944 systemd.cpp:136] Required functionality
> `Delegate` was introduced in Version `218`. Your system may not function
> properly; however since some distributions have patched systemd packages,
> your system may still be functional. This is why we keep running. See
> MESOS-3352 for more information
> I1120 11:39:37.938351 29944 systemd.cpp:210] Started systemd slice
> `mesos_executors.slice`
> I1120 11:39:37.940218 29962 containerizer.cpp:618] Starting container
> '1ea741a9-5edf-4910-ae64-f8d53f74e31e' for executor 'test_executor' of
> framework ''
> I1120 11:39:37.943042 29959 provisioner.cpp:289] Provisioning image rootfs
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/7d97f8ac-ee57-4c83-b2d1-4332e25c89ae'
> for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> I1120 11:39:49.571781 29958 provisioner.cpp:289] Provisioning image rootfs
> '/tmp/LinuxFilesystemIsolatorTest_ROOT_ImageInVolumeWithRootFilesystem_ZBw23E/provisioner/containers/1ea741a9-5edf-4910-ae64-f8d53f74e31e/backends/copy/rootfses/0256b892-e737-4d3d-89ea-74cf0e96eaf6'
> for container 1ea741a9-5edf-4910-ae64-f8d53f74e31e
> ../../src/tests/containerizer/filesystem_isolator_tests.cpp:806: Failure
> Failed to wait 15secs for launch
> [ FAILED ] LinuxFilesystemIsolatorTest.ROOT_ImageInVolumeWithRootFilesystem
> (55076 ms)
> [--] 1 test from LinuxFilesystemIsolatorTest (55076 ms total)
> {noformat}
> The following vagrant generator was used:
> {noformat}
> cat << EOF > Vagrantfile
> # -*- mode: ruby -*-" >
> # vi: set ft=ruby :
> Vagrant.configure(2) do |config|
> # Disable shared folder to prevent certain kernel module dependencies.
> config.vm.synced_folder ".", "/vagrant", disabled: true
> config.vm.hostname = "centos71"
> config.vm.box = "bento/centos-7.1"
> config.vm.provider "virtualbox" do |vb|
> vb.memory = 16384
> vb.cpus = 8
> end
> config.vm.provider "vmware_fusion" do |vb|
> vb.memory = 9216
> vb.cpus = 4
> end
> config.vm.provision "shell", inline: <<-SHELL
> sudo yum -y update systemd
> sudo yum install -y tar wget
> sudo wget
> http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo
> -O /etc/yum.repos.d/epel-apache-maven.repo
> sudo yum groupinstall -y "Development Tools"
> sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel
> zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5
> apr-devel subversion-devel apr-util-devel
> sudo yum install -y git
> sudo yum install -y docker
> sudo service docker start
> sudo docker info
> #sudo wget -qO- https://get.docker.com/ | sh
> SHELL
> end
> EOF
> vagrant up
> vagrant reload
> vagrant ssh -c "
> git clone https://github.com/apache/mesos.git mesos
> cd mesos
> git checkout -b 0.26.0-rc1 0.26.0-rc1
> ./bootstrap
> mkdir build
> cd build
> ../configure
> make -j4 check
> #make -j4 distcheck
> sudo ./bin/mesos-tests.sh
> #make clean
> #../configure --enable-libevent --enable-ssl
> #GTEST_FILTER="" make check
> #sudo ./bin/mesos-tests.sh
> "
> {noformat}
> Additionally, {{/etc/hosts}} was edited to contain hostname and IP (allowing
> a pass of the bridged docker executor tests).
> {noformat}
> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.218.135 centos71
> {noformat}
--
Thi
[jira] [Commented] (MESOS-2307) Add a Future state for gone processes
[
https://issues.apache.org/jira/browse/MESOS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018097#comment-15018097
]
Alexander Rojas commented on MESOS-2307:
This behavior is known in literature as breaking a promise. In fact, C++ 11
futures will set the future to the
[{{std::future_exception}}|http://www.cplusplus.com/reference/future/future_error/?kw=future_error]
with code
[{{broken_promise}}|http://www.cplusplus.com/reference/future/future_errc/] if
they run in this situation.
I feel that is akin to failing our futures when the futures are being destroyed
and not set. I have a small patch which fixes the issue, but there is a comment
there which I am not sure about, so once it is clear I will publish it.
> Add a Future state for gone processes
> -
>
> Key: MESOS-2307
> URL: https://issues.apache.org/jira/browse/MESOS-2307
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Alexander Rukletsov
>
> If the libprocess process is terminated, we can still dispatch calls to it as
> long as we have a {{UPID}}. In this case the future will be pending forever.
> Instead, it would be better to introduce a separate state for such case, e.g.
> {{Disconnected}}, {{Abandoned}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3968) DiskQuotaTest.SlaveRecovery is flaky
Benjamin Mahler created MESOS-3968:
--
Summary: DiskQuotaTest.SlaveRecovery is flaky
Key: MESOS-3968
URL: https://issues.apache.org/jira/browse/MESOS-3968
Project: Mesos
Issue Type: Bug
Components: test
Reporter: Benjamin Mahler
{noformat: title=Failed Run}
[ RUN ] DiskQuotaTest.SlaveRecovery
I1120 12:02:54.015383 29806 leveldb.cpp:176] Opened db in 2.965411ms
I1120 12:02:54.018033 29806 leveldb.cpp:183] Compacted db in 2.585354ms
I1120 12:02:54.018175 29806 leveldb.cpp:198] Created db iterator in 27134ns
I1120 12:02:54.018275 29806 leveldb.cpp:204] Seeked to beginning of db in 3025ns
I1120 12:02:54.018375 29806 leveldb.cpp:273] Iterated through 0 keys in the db
in 679ns
I1120 12:02:54.018491 29806 replica.cpp:780] Replica recovered with log
positions 0 -> 0 with 1 holes and 0 unlearned
I1120 12:02:54.021386 29838 recover.cpp:449] Starting replica recovery
I1120 12:02:54.021692 29838 recover.cpp:475] Replica is in EMPTY status
I1120 12:02:54.022189 29827 master.cpp:367] Master
9a3c45ec-28b3-49e6-a83f-1f2035cc1105 (a51e6bb03b55) started on
172.17.5.188:41228
I1120 12:02:54.022212 29827 master.cpp:369] Flags at startup: --acls=""
--allocation_interval="1secs" --allocator="HierarchicalDRF"
--authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
--authorizers="local" --credentials="/tmp/DsMniF/credentials"
--framework_sorter="drf" --help="false" --hostname_lookup="true"
--initialize_driver_logging="true" --log_auto_initialize="true"
--logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
--quiet="false" --recovery_slave_removal_limit="100%"
--registry="replicated_log" --registry_fetch_timeout="1mins"
--registry_store_timeout="25secs" --registry_strict="true"
--root_submissions="true" --slave_ping_timeout="15secs"
--slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
--webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui"
--work_dir="/tmp/DsMniF/master" --zk_session_timeout="10secs"
I1120 12:02:54.022557 29827 master.cpp:414] Master only allowing authenticated
frameworks to register
I1120 12:02:54.022569 29827 master.cpp:419] Master only allowing authenticated
slaves to register
I1120 12:02:54.022578 29827 credentials.hpp:37] Loading credentials for
authentication from '/tmp/DsMniF/credentials'
I1120 12:02:54.022896 29827 master.cpp:458] Using default 'crammd5'
authenticator
I1120 12:02:54.023217 29827 master.cpp:495] Authorization enabled
I1120 12:02:54.023512 29831 whitelist_watcher.cpp:79] No whitelist given
I1120 12:02:54.023814 29833 replica.cpp:676] Replica in EMPTY status received a
broadcasted recover request from (562)@172.17.5.188:41228
I1120 12:02:54.023519 29832 hierarchical.cpp:153] Initialized hierarchical
allocator process
I1120 12:02:54.025997 29831 recover.cpp:195] Received a recover response from a
replica in EMPTY status
I1120 12:02:54.027042 29832 recover.cpp:566] Updating replica status to STARTING
I1120 12:02:54.027354 29830 master.cpp:1612] The newly elected leader is
master@172.17.5.188:41228 with id 9a3c45ec-28b3-49e6-a83f-1f2035cc1105
I1120 12:02:54.027385 29830 master.cpp:1625] Elected as the leading master!
I1120 12:02:54.027403 29830 master.cpp:1385] Recovering from registrar
I1120 12:02:54.027679 29830 registrar.cpp:309] Recovering registrar
I1120 12:02:54.028439 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 1.195171ms
I1120 12:02:54.028539 29840 replica.cpp:323] Persisted replica status to
STARTING
I1120 12:02:54.028944 29840 recover.cpp:475] Replica is in STARTING status
I1120 12:02:54.030910 29840 replica.cpp:676] Replica in STARTING status
received a broadcasted recover request from (563)@172.17.5.188:41228
I1120 12:02:54.031429 29840 recover.cpp:195] Received a recover response from a
replica in STARTING status
I1120 12:02:54.032032 29840 recover.cpp:566] Updating replica status to VOTING
I1120 12:02:54.032816 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 496492ns
I1120 12:02:54.032982 29840 replica.cpp:323] Persisted replica status to VOTING
I1120 12:02:54.033254 29840 recover.cpp:580] Successfully joined the Paxos group
I1120 12:02:54.033562 29840 recover.cpp:464] Recover process terminated
I1120 12:02:54.034631 29839 log.cpp:661] Attempting to start the writer
I1120 12:02:54.036386 29834 replica.cpp:496] Replica received implicit promise
request from (564)@172.17.5.188:41228 with proposal 1
I1120 12:02:54.037082 29834 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 642707ns
I1120 12:02:54.037116 29834 replica.cpp:345] Persisted promised to 1
I1120 12:02:54.038153 29834 coordinator.cpp:240] Coordinator attempting to fill
missing positions
I1120 12:02:54.039929 29828 replica.cpp:391] Replica received explicit promise
request from (565)@172.17.5.188:41228 for position 0 with proposal 2
I1120 1
[jira] [Created] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.
Bernd Mathiske created MESOS-3969:
-
Summary: Failing 'make distcheck' on Debian 8, somehow SSL-related.
Key: MESOS-3969
URL: https://issues.apache.org/jira/browse/MESOS-3969
Project: Mesos
Issue Type: Bug
Affects Versions: 0.26.0
Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
Vagrantfile see MESOS-3957
Reporter: Bernd Mathiske
As non-root: make distcheck.
{noformat}
/bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
/bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log
mesos mesos-execute mesos-resolve
'/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
libtool: install: /usr/bin/install -c .libs/mesos-local
/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
libtool: install: /usr/bin/install -c .libs/mesos-log
/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
libtool: install: /usr/bin/install -c .libs/mesos
/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
libtool: install: /usr/bin/install -c .libs/mesos-execute
/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
libtool: install: /usr/bin/install -c .libs/mesos-resolve
/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
Traceback (most recent call last):
File "", line 1, in
File
"/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
line 11, in
from pip.vcs import git, mercurial, subversion, bazaar # noqa
File
"/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
line 9, in
from pip.download import path_to_url
File
"/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
line 22, in
from pip._vendor import requests, six
File
"/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
line 53, in
from .packages.urllib3.contrib import pyopenssl
File
"/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
line 70, in
ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
Traceback (most recent call last):
File "", line 1, in
File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3971) Runing task counters in mesos UI are racy
Ian Babrou created MESOS-3971: - Summary: Runing task counters in mesos UI are racy Key: MESOS-3971 URL: https://issues.apache.org/jira/browse/MESOS-3971 Project: Mesos Issue Type: Bug Components: webui Affects Versions: 0.25.0 Reporter: Ian Babrou On slave's page task counters in the left panel are racy. The reason for that is: in src/webui/master/static/js/controllers.js properties like "staged_tasks" are populated from both master and slave states. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3073) Introduce HTTP endpoints for Quota
[ https://issues.apache.org/jira/browse/MESOS-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018167#comment-15018167 ] Joerg Schad commented on MESOS-3073: DELETE/remove Endpoint https://reviews.apache.org/r/40544/ Tests > Introduce HTTP endpoints for Quota > -- > > Key: MESOS-3073 > URL: https://issues.apache.org/jira/browse/MESOS-3073 > Project: Mesos > Issue Type: Improvement >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: mesosphere > > We need to implement the HTTP endpoints for Quota as outlined in the Design > Doc: > (https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3968) DiskQuotaTest.SlaveRecovery is flaky
[
https://issues.apache.org/jira/browse/MESOS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018187#comment-15018187
]
Benjamin Mahler commented on MESOS-3968:
Interestingly, in the failing case it appears the slave never received the
executor's status update message. That is pretty alarming, don't think we've
seen this before.
> DiskQuotaTest.SlaveRecovery is flaky
>
>
> Key: MESOS-3968
> URL: https://issues.apache.org/jira/browse/MESOS-3968
> Project: Mesos
> Issue Type: Bug
> Components: test
>Reporter: Benjamin Mahler
> Labels: flaky-test
>
> {noformat: title=Failed Run}
> [ RUN ] DiskQuotaTest.SlaveRecovery
> I1120 12:02:54.015383 29806 leveldb.cpp:176] Opened db in 2.965411ms
> I1120 12:02:54.018033 29806 leveldb.cpp:183] Compacted db in 2.585354ms
> I1120 12:02:54.018175 29806 leveldb.cpp:198] Created db iterator in 27134ns
> I1120 12:02:54.018275 29806 leveldb.cpp:204] Seeked to beginning of db in
> 3025ns
> I1120 12:02:54.018375 29806 leveldb.cpp:273] Iterated through 0 keys in the
> db in 679ns
> I1120 12:02:54.018491 29806 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1120 12:02:54.021386 29838 recover.cpp:449] Starting replica recovery
> I1120 12:02:54.021692 29838 recover.cpp:475] Replica is in EMPTY status
> I1120 12:02:54.022189 29827 master.cpp:367] Master
> 9a3c45ec-28b3-49e6-a83f-1f2035cc1105 (a51e6bb03b55) started on
> 172.17.5.188:41228
> I1120 12:02:54.022212 29827 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/DsMniF/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui"
> --work_dir="/tmp/DsMniF/master" --zk_session_timeout="10secs"
> I1120 12:02:54.022557 29827 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1120 12:02:54.022569 29827 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1120 12:02:54.022578 29827 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/DsMniF/credentials'
> I1120 12:02:54.022896 29827 master.cpp:458] Using default 'crammd5'
> authenticator
> I1120 12:02:54.023217 29827 master.cpp:495] Authorization enabled
> I1120 12:02:54.023512 29831 whitelist_watcher.cpp:79] No whitelist given
> I1120 12:02:54.023814 29833 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (562)@172.17.5.188:41228
> I1120 12:02:54.023519 29832 hierarchical.cpp:153] Initialized hierarchical
> allocator process
> I1120 12:02:54.025997 29831 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1120 12:02:54.027042 29832 recover.cpp:566] Updating replica status to
> STARTING
> I1120 12:02:54.027354 29830 master.cpp:1612] The newly elected leader is
> master@172.17.5.188:41228 with id 9a3c45ec-28b3-49e6-a83f-1f2035cc1105
> I1120 12:02:54.027385 29830 master.cpp:1625] Elected as the leading master!
> I1120 12:02:54.027403 29830 master.cpp:1385] Recovering from registrar
> I1120 12:02:54.027679 29830 registrar.cpp:309] Recovering registrar
> I1120 12:02:54.028439 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.195171ms
> I1120 12:02:54.028539 29840 replica.cpp:323] Persisted replica status to
> STARTING
> I1120 12:02:54.028944 29840 recover.cpp:475] Replica is in STARTING status
> I1120 12:02:54.030910 29840 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (563)@172.17.5.188:41228
> I1120 12:02:54.031429 29840 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1120 12:02:54.032032 29840 recover.cpp:566] Updating replica status to VOTING
> I1120 12:02:54.032816 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 496492ns
> I1120 12:02:54.032982 29840 replica.cpp:323] Persisted replica status to
> VOTING
> I1120 12:02:54.033254 29840 recover.cpp:580] Successfully joined the Paxos
> group
> I1120 12:02:54.033562 29840 recover.cpp:464] Recover process terminated
> I1120 12:02:54.034631 29839 log.cpp:661] Attempting to start the writ
[jira] [Commented] (MESOS-3970) CPU usage in mesos ui is always empty
[ https://issues.apache.org/jira/browse/MESOS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018171#comment-15018171 ] Ian Babrou commented on MESOS-3970: --- https://reviews.apache.org/r/40545/ > CPU usage in mesos ui is always empty > - > > Key: MESOS-3970 > URL: https://issues.apache.org/jira/browse/MESOS-3970 > Project: Mesos > Issue Type: Bug > Components: webui >Reporter: Ian Babrou > > In fact, it's NaN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3970) CPU usage in mesos ui is always empty
Ian Babrou created MESOS-3970: - Summary: CPU usage in mesos ui is always empty Key: MESOS-3970 URL: https://issues.apache.org/jira/browse/MESOS-3970 Project: Mesos Issue Type: Bug Components: webui Reporter: Ian Babrou In fact, it's NaN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3972) Framework CPU counters on slave page are always zero
Ian Babrou created MESOS-3972: - Summary: Framework CPU counters on slave page are always zero Key: MESOS-3972 URL: https://issues.apache.org/jira/browse/MESOS-3972 Project: Mesos Issue Type: Bug Components: webui Affects Versions: 0.25.0 Reporter: Ian Babrou Don't know why, but system and user are always zero, but total is not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3972) Framework CPU counters on slave page are always zero
[ https://issues.apache.org/jira/browse/MESOS-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018200#comment-15018200 ] Ian Babrou commented on MESOS-3972: --- https://reviews.apache.org/r/40546/ > Framework CPU counters on slave page are always zero > > > Key: MESOS-3972 > URL: https://issues.apache.org/jira/browse/MESOS-3972 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.25.0 >Reporter: Ian Babrou > > Don't know why, but system and user are always zero, but total is not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3968) DiskQuotaTest.SlaveRecovery is flaky
[
https://issues.apache.org/jira/browse/MESOS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018205#comment-15018205
]
Benjamin Mahler commented on MESOS-3968:
Encountered another issue that made this test flaky, the original issue for
this ticket is still unresolved:
{noformat}
commit aa8de47d4661996f252672d8dab4252a7d377645
Author: Benjamin Mahler
Date: Fri Nov 20 17:05:13 2015 +0100
Fixed a flaky issue in DiskQuotaTest.SlaveRecovery.
{noformat}
> DiskQuotaTest.SlaveRecovery is flaky
>
>
> Key: MESOS-3968
> URL: https://issues.apache.org/jira/browse/MESOS-3968
> Project: Mesos
> Issue Type: Bug
> Components: test
>Reporter: Benjamin Mahler
> Labels: flaky-test
>
> {noformat: title=Failed Run}
> [ RUN ] DiskQuotaTest.SlaveRecovery
> I1120 12:02:54.015383 29806 leveldb.cpp:176] Opened db in 2.965411ms
> I1120 12:02:54.018033 29806 leveldb.cpp:183] Compacted db in 2.585354ms
> I1120 12:02:54.018175 29806 leveldb.cpp:198] Created db iterator in 27134ns
> I1120 12:02:54.018275 29806 leveldb.cpp:204] Seeked to beginning of db in
> 3025ns
> I1120 12:02:54.018375 29806 leveldb.cpp:273] Iterated through 0 keys in the
> db in 679ns
> I1120 12:02:54.018491 29806 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1120 12:02:54.021386 29838 recover.cpp:449] Starting replica recovery
> I1120 12:02:54.021692 29838 recover.cpp:475] Replica is in EMPTY status
> I1120 12:02:54.022189 29827 master.cpp:367] Master
> 9a3c45ec-28b3-49e6-a83f-1f2035cc1105 (a51e6bb03b55) started on
> 172.17.5.188:41228
> I1120 12:02:54.022212 29827 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/DsMniF/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/mesos/mesos-0.26.0/_inst/share/mesos/webui"
> --work_dir="/tmp/DsMniF/master" --zk_session_timeout="10secs"
> I1120 12:02:54.022557 29827 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1120 12:02:54.022569 29827 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1120 12:02:54.022578 29827 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/DsMniF/credentials'
> I1120 12:02:54.022896 29827 master.cpp:458] Using default 'crammd5'
> authenticator
> I1120 12:02:54.023217 29827 master.cpp:495] Authorization enabled
> I1120 12:02:54.023512 29831 whitelist_watcher.cpp:79] No whitelist given
> I1120 12:02:54.023814 29833 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (562)@172.17.5.188:41228
> I1120 12:02:54.023519 29832 hierarchical.cpp:153] Initialized hierarchical
> allocator process
> I1120 12:02:54.025997 29831 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1120 12:02:54.027042 29832 recover.cpp:566] Updating replica status to
> STARTING
> I1120 12:02:54.027354 29830 master.cpp:1612] The newly elected leader is
> master@172.17.5.188:41228 with id 9a3c45ec-28b3-49e6-a83f-1f2035cc1105
> I1120 12:02:54.027385 29830 master.cpp:1625] Elected as the leading master!
> I1120 12:02:54.027403 29830 master.cpp:1385] Recovering from registrar
> I1120 12:02:54.027679 29830 registrar.cpp:309] Recovering registrar
> I1120 12:02:54.028439 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.195171ms
> I1120 12:02:54.028539 29840 replica.cpp:323] Persisted replica status to
> STARTING
> I1120 12:02:54.028944 29840 recover.cpp:475] Replica is in STARTING status
> I1120 12:02:54.030910 29840 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (563)@172.17.5.188:41228
> I1120 12:02:54.031429 29840 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1120 12:02:54.032032 29840 recover.cpp:566] Updating replica status to VOTING
> I1120 12:02:54.032816 29840 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 496492ns
> I1120 12:02:54.032982 29840 replica.cpp:323] Persisted replica status to
> VOTING
> I1120 12:02:54.033254 29840 recover.cpp:580] Successfully joined the Paxos
> group
> I1120 12:02:5
[jira] [Commented] (MESOS-3946) Test for role management
[ https://issues.apache.org/jira/browse/MESOS-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018209#comment-15018209 ] Marco Massenzio commented on MESOS-3946: Can you please add more details as to what you are proposing here, what's missing, etc.? thanks. > Test for role management > > > Key: MESOS-3946 > URL: https://issues.apache.org/jira/browse/MESOS-3946 > Project: Mesos > Issue Type: Task >Reporter: Yong Qiao Wang >Assignee: Yong Qiao Wang > > Add test for role dynamic configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3947) Authenticate /roles request
[
https://issues.apache.org/jira/browse/MESOS-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018212#comment-15018212
]
Marco Massenzio commented on MESOS-3947:
This makes obviously a lot of sense (although, I'm not sure why the {{GET}}
should not be authenticated, so it'd be great if you could elaborate that
point).
However, I believe, this should be part of a broader activity involving *all*
endpoints, within the scope of the {{HttpAuthorizer}} effort.
Please see MESOS-2297 for more details.
> Authenticate /roles request
> ---
>
> Key: MESOS-3947
> URL: https://issues.apache.org/jira/browse/MESOS-3947
> Project: Mesos
> Issue Type: Task
>Reporter: Yong Qiao Wang
>Assignee: Yong Qiao Wang
>
> /roles requests except GET method need to be authenticated.
> This ticket will authenticate /roles requests using credentials provided by
> the `Authorization` field of the HTTP request. This is similar to how
> authentication is implemented in `Master::Http`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3947) Authenticate /roles request
[
https://issues.apache.org/jira/browse/MESOS-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018212#comment-15018212
]
Marco Massenzio edited comment on MESOS-3947 at 11/20/15 4:13 PM:
--
This makes obviously a lot of sense (although, I'm not sure why the {{GET}}
should not be authenticated, so it'd be great if you could elaborate that
point).
However, I believe, this should be part of a broader activity involving *all*
endpoints, within the scope of the {{HttpAuthenticator}} effort.
Please see MESOS-2297 for more details.
was (Author: marco-mesos):
This makes obviously a lot of sense (although, I'm not sure why the {{GET}}
should not be authenticated, so it'd be great if you could elaborate that
point).
However, I believe, this should be part of a broader activity involving *all*
endpoints, within the scope of the {{HttpAuthorizer}} effort.
Please see MESOS-2297 for more details.
> Authenticate /roles request
> ---
>
> Key: MESOS-3947
> URL: https://issues.apache.org/jira/browse/MESOS-3947
> Project: Mesos
> Issue Type: Task
>Reporter: Yong Qiao Wang
>Assignee: Yong Qiao Wang
>
> /roles requests except GET method need to be authenticated.
> This ticket will authenticate /roles requests using credentials provided by
> the `Authorization` field of the HTTP request. This is similar to how
> authentication is implemented in `Master::Http`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3948) Authorize /roles request
[
https://issues.apache.org/jira/browse/MESOS-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018215#comment-15018215
]
Marco Massenzio commented on MESOS-3948:
Same comment as in MESOS-3947, this should be part of a broader effort around
implementing the {{HttpAuthorizer}} interface.
See MESOS-2945
> Authorize /roles request
>
>
> Key: MESOS-3948
> URL: https://issues.apache.org/jira/browse/MESOS-3948
> Project: Mesos
> Issue Type: Task
>Reporter: Yong Qiao Wang
>Assignee: Yong Qiao Wang
>
> When /roles are requested it should authorize the updated role.
> This ticket will authorize /roles requests with ACLs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3964) LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.
[
https://issues.apache.org/jira/browse/MESOS-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018223#comment-15018223
]
Marco Massenzio commented on MESOS-3964:
Same as the other ones, it would be great to know whether these are {{0.26}}
regressions or have been failing for a while (or, even, did they ever pass?).
Thanks, this is a release blocker.
> LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs and
> LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs_Big_Quota fail on Debian 8.
> ---
>
> Key: MESOS-3964
> URL: https://issues.apache.org/jira/browse/MESOS-3964
> Project: Mesos
> Issue Type: Bug
> Components: isolation, test
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile: see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Greg Mann
> Labels: mesosphere
>
> sudo ./bin/mesos-test.sh
> --gtest_filter="LimitedCpuIsolatorTest.ROOT_CGROUPS_Cfs"
> {noformat}
> ...
> F1119 14:34:52.514742 30706 isolator_tests.cpp:455] CHECK_SOME(isolator):
> Failed to find 'cpu.cfs_quota_us'. Your kernel might be too old to use the
> CFS cgroups feature.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2000) Support libprocess tracing
[ https://issues.apache.org/jira/browse/MESOS-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018226#comment-15018226 ] Marco Massenzio commented on MESOS-2000: [~jpe...@apache.org] - yes, we have something working as part of a "hackathon" project: this ticket is about getting the code into shape and release. > Support libprocess tracing > --- > > Key: MESOS-2000 > URL: https://issues.apache.org/jira/browse/MESOS-2000 > Project: Mesos > Issue Type: Improvement >Reporter: Timothy Chen > > Adding the ability to trace the libprocess calls adds a lot of opportunity > for easier debugging, help understanding how mesos work, profiling, and also > visualizations. > Ideally we also want to include timing information as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3971) Runing task counters in mesos UI are racy
[ https://issues.apache.org/jira/browse/MESOS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018231#comment-15018231 ] Ian Babrou commented on MESOS-3971: --- In fact, the whole state is racy. On initial load I see slave hostname and start time instead of master hostname and start time. > Runing task counters in mesos UI are racy > - > > Key: MESOS-3971 > URL: https://issues.apache.org/jira/browse/MESOS-3971 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.25.0 >Reporter: Ian Babrou > > On slave's page task counters in the left panel are racy. > The reason for that is: in src/webui/master/static/js/controllers.js > properties like "staged_tasks" are populated from both master and slave > states. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3949) User CGroup Isolation tests fail on Centos 6.
[
https://issues.apache.org/jira/browse/MESOS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3949:
--
Assignee: Timothy Chen (was: Joris Van Remoortere)
Can you please coordinate with [~jojy] and [~greggomann] and figure out whether
these tests ever passed, and/or what the issue may be here?
I have a suspicion these tests keep on failing every release, but can't be sure.
Thanks!
> User CGroup Isolation tests fail on Centos 6.
> -
>
> Key: MESOS-3949
> URL: https://issues.apache.org/jira/browse/MESOS-3949
> Project: Mesos
> Issue Type: Bug
> Components: isolation
>Affects Versions: 0.26.0
> Environment: CentOS 6.6, gcc 4.8.1, on vagrant libvirt, 16GB, 8 CPUs,
> ../configure --enable-libevent --enable-ssl
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
> Labels: mesosphere
>
> UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup and
> UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup fail on CentOS 6.6 with
> similar output when libevent and SSL are enabled.
> {noformat}
> sudo ./bin/mesos-tests.sh
> --gtest_filter="UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from UserCgroupIsolatorTest/0, where TypeParam =
> mesos::internal::slave::CgroupsMemIsolatorProcess
> userdel: user 'mesos.test.unprivileged.user' does not exist
> [ RUN ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup
> I1118 16:53:35.273717 30249 mem.cpp:605] Started listening for OOM events for
> container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.274538 30249 mem.cpp:725] Started listening on low memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.275164 30249 mem.cpp:725] Started listening on medium memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.275784 30249 mem.cpp:725] Started listening on critical memory
> pressure events for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.276448 30249 mem.cpp:356] Updated 'memory.soft_limit_in_bytes'
> to 1GB for container 867a829e-4a26-43f5-86e0-938bf1f47688
> I1118 16:53:35.277331 30249 mem.cpp:391] Updated 'memory.limit_in_bytes' to
> 1GB for container 867a829e-4a26-43f5-86e0-938bf1f47688
> -bash:
> /sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/cgroup.procs:
> No such file or directory
> mkdir: cannot create directory
> `/sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/user': No
> such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1307: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'mkdir " +
> path::join(flags.cgroups_hierarchy, userCgroup) + "'")
> Actual: 256
> Expected: 0
> -bash:
> /sys/fs/cgroup/memory/mesos/867a829e-4a26-43f5-86e0-938bf1f47688/user/cgroup.procs:
> No such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1316: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'echo $$ >" +
> path::join(flags.cgroups_hierarchy, userCgroup, "cgroup.procs") + "'")
> Actual: 256
> Expected: 0
> [ FAILED ] UserCgroupIsolatorTest/0.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsMemIsolatorProcess (149 ms)
> {noformat}
> {noformat}
> sudo ./bin/mesos-tests.sh
> --gtest_filter="UserCgroupIsolatorTest/1.ROOT_CGROUPS_UserCgroup" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 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
> I1118 17:01:00.550706 30357 cpushare.cpp:392] Updated 'cpu.shares' to 1024
> (cpus 1) for container e57f4343-1a97-4b44-b347-803be47ace80
> -bash:
> /sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/cgroup.procs:
> No such file or directory
> mkdir: cannot create directory
> `/sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/user': No
> such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1307: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'mkdir " +
> path::join(flags.cgroups_hierarchy, userCgroup) + "'")
> Actual: 256
> Expected: 0
> -bash:
> /sys/fs/cgroup/cpuacct/mesos/e57f4343-1a97-4b44-b347-803be47ace80/user/cgroup.procs:
> No such file or directory
> ../../src/tests/containerizer/isolator_tests.cpp:1316: Failure
> Value of: os::system( "su - " + UNPRIVILEGED_USERNAME + " -c 'echo $$ >" +
> path::join
[jira] [Assigned] (MESOS-3953) DockerTest.ROOT_DOCKER_CheckPortResource fails.
[
https://issues.apache.org/jira/browse/MESOS-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3953:
--
Assignee: Timothy Chen
Release 0.26 blocker.
As for the others, can you please coordinate with [~jojy] and [~greggomann] and
verify whether this is a regression and/or the root cause?
thanks!
> DockerTest.ROOT_DOCKER_CheckPortResource fails.
> ---
>
> Key: MESOS-3953
> URL: https://issues.apache.org/jira/browse/MESOS-3953
> Project: Mesos
> Issue Type: Bug
> Environment: CentOS Linux release 7.1.1503 (Core),
> gcc (GCC) 4.8.3,
> Docker version 1.9.0, build 76d6bc9
>Reporter: Till Toenshoff
>Assignee: Timothy Chen
>
> The following is happening on my CentOS 7 installation (100% reproducible).
> {noformat}
> [ RUN ] DockerTest.ROOT_DOCKER_CheckPortResource
> I1118 08:18:50.336110 20979 docker.cpp:684] Running docker -H
> unix:///var/run/docker.sock rm -f -v mesos-docker-port-resource-test
> I1118 08:18:50.413763 20979 resources.cpp:474] Parsing resources as JSON
> failed: ports:[9998-];ports:[10001-11000]
> Trying semicolon-delimited string format instead
> I1118 08:18:50.414670 20979 resources.cpp:474] Parsing resources as JSON
> failed: ports:[9998-];ports:[1-11000]
> Trying semicolon-delimited string format instead
> I1118 08:18:50.415073 20979 docker.cpp:564] Running docker -H
> unix:///var/run/docker.sock run -e MESOS_SANDBOX=/mnt/mesos/sandbox -e
> MESOS_CONTAINER_NAME=mesos-docker-port-resource-test -v
> /tmp/DockerTest_ROOT_DOCKER_CheckPortResource_4e34OB:/mnt/mesos/sandbox --net
> bridge -p 1:80 --name mesos-docker-port-resource-test busybox true
> ../../src/tests/containerizer/docker_tests.cpp:338: Failure
> (run).failure(): Container exited on error: exited with status 1
> I1118 08:18:50.717136 20979 docker.cpp:842] Running docker -H
> unix:///var/run/docker.sock ps -a
> I1118 08:18:50.819042 20999 docker.cpp:723] Running docker -H
> unix:///var/run/docker.sock inspect mesos-docker-port-resource-test
> I1118 08:18:50.924579 20979 docker.cpp:684] Running docker -H
> unix:///var/run/docker.sock rm -f -v
> 67781b79c7641a6450c3ddb4ba13112b6f5a50060eac3f65cac3ad57a2a527ea
> [ FAILED ] DockerTest.ROOT_DOCKER_CheckPortResource
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3929) Implement submit-reviews.py for Mesos committers.
[ https://issues.apache.org/jira/browse/MESOS-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018248#comment-15018248 ] Marco Massenzio commented on MESOS-3929: Can you please add more details? > Implement submit-reviews.py for Mesos committers. > - > > Key: MESOS-3929 > URL: https://issues.apache.org/jira/browse/MESOS-3929 > Project: Mesos > Issue Type: Bug >Reporter: Artem Harutyunyan > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3272) CgroupsAnyHierarchyWithCpuMemoryTest.ROOT_CGROUPS_FreezeNonFreezer is flaky.
[
https://issues.apache.org/jira/browse/MESOS-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018253#comment-15018253
]
Till Toenshoff commented on MESOS-3272:
---
I am seeing this flaky test (~ 10%) on CentOS 6.7 as well.
{noformat}
GLOG_v=2 sudo ./bin/mesos-tests.sh
--gtest_filter="CgroupsAnyHierarchyWithCpuMemoryTest.ROOT_CGROUPS_FreezeNonFreezer"
--gtest_repeat=100 --gtest_break_on_failure --verbose
{noformat}
{noformat}
[ ... ]
Repeating all tests (iteration 7) . . .
Note: Google Test filter =
CgroupsAnyHierarchyWithCpuMemoryTest.ROOT_CGROUPS_FreezeNonFreezer-MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward:DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping:PerfEventIsolatorTest.ROOT_CGROUPS_Sample:UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup:CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy:CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf:PerfTest.ROOT_Events:PerfTest.ROOT_Sample:PerfTest.Parse:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/0:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/1:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/2:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/3:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/4:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/5:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/6:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/7:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/8:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/9:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/10:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/11:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/12:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/13:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/14:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/15:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/16:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/17:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/18:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/19:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/20:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/21:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/22:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/23:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/24:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/25:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/26:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/27:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/28:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/29:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/30:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/31:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/32:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/33:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/34:SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.AddAndUpdateSlave/35: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 CgroupsAnyHierarchyWithCpuMemoryTest
I1120 16:22:04.135941 27505 process.cpp:2426] Spawned process
__latch__(33)@127.0.0.1:33586
[ RUN ] CgroupsAnyHierarchyWithCpuMemoryTest.ROOT_CGROUPS_FreezeNonFreezer
I1120 16:22:04.135995 27521 process.cpp:2436] Resuming __gc__@127.0.0.1:33586
at 2015-11-20 16:22:04.135983104+00:00
I1120 16:22:04.136077 27521 process.cpp:2436] Resuming
__latch__(33)@127.0.0.1:33586 at 2015-11-20 16:22:04.136075008+00:00
I1120 16:22:04.136106 27521 process.cpp:2541] Cleaning up
__latch__(33)@127.0.0.1:33586
I1120 16:22:04.136154 27521 process.cpp:2436] Resuming __gc__@127.0.0.1:33586
at 2015-11-20 16:22:04.136152064+00:00
I1120 16:22:04.138380 27505 cgroups.cpp:2429] Freezing cgr
[jira] [Updated] (MESOS-3971) Running task counters in mesos UI is racy.
[ https://issues.apache.org/jira/browse/MESOS-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-3971: --- Summary: Running task counters in mesos UI is racy. (was: Runing task counters in mesos UI are racy) > Running task counters in mesos UI is racy. > -- > > Key: MESOS-3971 > URL: https://issues.apache.org/jira/browse/MESOS-3971 > Project: Mesos > Issue Type: Bug > Components: webui >Affects Versions: 0.25.0 >Reporter: Ian Babrou > > On slave's page task counters in the left panel are racy. > The reason for that is: in src/webui/master/static/js/controllers.js > properties like "staged_tasks" are populated from both master and slave > states. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3933) Use a simpler realm for "Unauthorized" HTTP responses.
[
https://issues.apache.org/jira/browse/MESOS-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018266#comment-15018266
]
Benjamin Mahler commented on MESOS-3933:
Is this backwards-compatible? And can we avoid using upper case here given
realm is case sensitive?
> Use a simpler realm for "Unauthorized" HTTP responses.
> --
>
> Key: MESOS-3933
> URL: https://issues.apache.org/jira/browse/MESOS-3933
> Project: Mesos
> Issue Type: Bug
> Components: HTTP API
>Reporter: Jan Schlicht
>Priority: Trivial
> Labels: easyfix, newbie
>
> Currently, if a HTTP request cannot be authorized, an {{Unauthorized}}
> response is returned using "Mesos master" for the {{realm}} parameter. While
> not strictly forbidden by the HTTP RFC, strings with spaces seem to be very
> uncommon for the {{realm}} parameter. A simpler realm such as "Mesos" should
> be used instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.
[
https://issues.apache.org/jira/browse/MESOS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3969:
--
Assignee: Joris Van Remoortere
This is a release blocker (I presume, assuming that this ever worked).
Can you please (a) find out what's the root cause and (b) whether this is a
regression (or maybe just a configuration issue on the test rig).
Thanks!
> Failing 'make distcheck' on Debian 8, somehow SSL-related.
> --
>
> Key: MESOS-3969
> URL: https://issues.apache.org/jira/browse/MESOS-3969
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Joris Van Remoortere
> Labels: build, build-failure, mesosphere
>
> As non-root: make distcheck.
> {noformat}
> /bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> /bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log
> mesos mesos-execute mesos-resolve
> '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> libtool: install: /usr/bin/install -c .libs/mesos-local
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
> libtool: install: /usr/bin/install -c .libs/mesos-log
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
> libtool: install: /usr/bin/install -c .libs/mesos
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
> libtool: install: /usr/bin/install -c .libs/mesos-execute
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
> libtool: install: /usr/bin/install -c .libs/mesos-resolve
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
> line 11, in
> from pip.vcs import git, mercurial, subversion, bazaar # noqa
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
> line 9, in
> from pip.download import path_to_url
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
> line 22, in
> from pip._vendor import requests, six
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
> line 53, in
> from .packages.urllib3.contrib import pyopenssl
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
> line 70, in
> ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3941) Using 'async' to invoke blocking functions will block work threads.
[
https://issues.apache.org/jira/browse/MESOS-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018285#comment-15018285
]
Benjamin Mahler commented on MESOS-3941:
[~tnachen] can you elaborate? The example in this ticket is referring to
incorrect usage of {{async}}. In particular, we need to eliminate blocking
functions like {{net::contentLength}} in favor of a non-blocking version.
> Using 'async' to invoke blocking functions will block work threads.
> ---
>
> Key: MESOS-3941
> URL: https://issues.apache.org/jira/browse/MESOS-3941
> Project: Mesos
> Issue Type: Bug
>Reporter: Jie Yu
>
> Saw a few occurrences in the code base. For instance:
> https://github.com/apache/mesos/blob/master/src/slave/containerizer/fetcher.cpp#L382
> The current implementation of 'async' will create a libprocess process. That
> means if the function is blocking, a worker thread will be blocked. If we
> have too many such instances, we might end up deadlocking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3961) Consider equality behavior for DiskInfo resource
[
https://issues.apache.org/jira/browse/MESOS-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3961:
--
Assignee: Greg Mann
> Consider equality behavior for DiskInfo resource
>
>
> Key: MESOS-3961
> URL: https://issues.apache.org/jira/browse/MESOS-3961
> Project: Mesos
> Issue Type: Bug
>Reporter: Neil Conway
>Assignee: Greg Mann
>Priority: Minor
> Labels: mesosphere, persistent-volumes
>
> Relevant code:
> {code}
> bool operator==(const Resource::DiskInfo& left, const Resource::DiskInfo&
> right)
> {
> // NOTE: We ignore 'volume' inside DiskInfo when doing comparison
> // because it describes how this resource will be used which has
> // nothing to do with the Resource object itself. A framework can
> // use this resource and specify different 'volume' every time it
> // uses it.
> if (left.has_persistence() != right.has_persistence()) {
> return false;
> }
> if (left.has_persistence()) {
> return left.persistence().id() == right.persistence().id();
> }
> return true;
> }
> {code}
> A consequence of this behavior is that if you pass the wrong path to a
> `destroy-volume` request (but there is a persistent volume that otherwise
> matches the request), the path will be ignored and the volume will be
> destroyed. Not clear if that is undesirable, but it does seem surprising.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3935) mesos-master crashes when a scheduler with an unresolvable hostname attempts to connect
[
https://issues.apache.org/jira/browse/MESOS-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15009153#comment-15009153
]
Marco Massenzio edited comment on MESOS-3935 at 11/20/15 4:44 PM:
--
This looks like a name resolution issue for the *master's* hostname and not the
scheduler's hostname. If looking up the hostname via ip doesn't work in your
network, you can use {{-- hostname}} or {{--hostname_lookup}} flags.
was (Author: vinodkone):
This looks like a name resolution issue for the *master's* hostname and not the
scheduler's hostname. If looking up the hostname via ip doesn't work in your
network, you can use "--hostname" or "--hostname_lookup" flags.
> mesos-master crashes when a scheduler with an unresolvable hostname attempts
> to connect
> ---
>
> Key: MESOS-3935
> URL: https://issues.apache.org/jira/browse/MESOS-3935
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.25.0
>Reporter: Hamza Faran
>
> {code}
> $ sudo mesos-master --ip=10.8.0.5 --work_dir=work_dir --authenticate
> --authenticate_slaves --credentials=credentials --port=5045
>
> I1117 07:05:15.371150 5852 main.cpp:229] Build: 2015-10-12 21:00:09 by root
>
>
> I1117 07:05:15.371314 5852 main.cpp:231] Version: 0.25.0
>
>
> I1117 07:05:15.371340 5852 main.cpp:234] Git tag: 0.25.0
>
>
> I1117 07:05:15.371366 5852 main.cpp:238] Git SHA:
> 2dd7f7ee115fe00b8e098b0a10762a4fa8f4600f
>
>
> I1117 07:05:15.371439 5852 main.cpp:252] Using 'HierarchicalDRF' allocator
>
>
> I1117 07:05:15.373845 5852 leveldb.cpp:176] Opened db in 2.267831ms
>
>
> I1117 07:05:15.374606 5852 leveldb.cpp:183] Compacted db in 678911ns
>
>
> I1117 07:05:15.374668 5852 leveldb.cpp:198] Created db iterator in 19310ns
>
>
> I1117 07:05:15.374775 5852 leveldb.cpp:204] Seeked to beginning of db in
> 79269ns
>
> I1117 07:05:15.374882 5852 leveldb.cpp:273] Iterated through 3 keys in the
> db in 79949ns
>
> I1117 07:05:15.374953 5852 replica.cpp:744] Replica recovered with log
> positions 91 -> 92 with 0 holes and 0 unlearned
>
> I1117 07:05:15.375820 5852 main.cpp:465] Starting Mesos master
>
>
> I1117 07:05:15.376049 5856 recover.cpp:449] Starting replica recovery
>
>
> I1117 07:05:15.376188 5858 recover.cpp:475] Replica is in VOTING status
>
>
> I1117 07:05:15.376332 5858 recover.cpp:464] Recover process terminated
>
>
> F1117 07:05:43.398336 5852 master.cpp:330] Failed to get hostname: Temporary
> failure in name resolution
>
> *** Check failure stack trace: ***
[jira] [Commented] (MESOS-3936) Document possible task state transitions for framework authors
[ https://issues.apache.org/jira/browse/MESOS-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018308#comment-15018308 ] Marco Massenzio commented on MESOS-3936: Great suggestion! Would love to do this together, as I really want to understand this in much greater detail. > Document possible task state transitions for framework authors > -- > > Key: MESOS-3936 > URL: https://issues.apache.org/jira/browse/MESOS-3936 > Project: Mesos > Issue Type: Documentation >Reporter: Neil Conway > Labels: documentation,, mesosphere > > We should document the possible ways in which the state of a task can evolve > over time; what happens when an agent is partitioned from the master; and > more generally, how we recommend that framework authors develop > fault-tolerant schedulers and do task state reconciliation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3959) Executor page of mesos ui does not show slave hostname
[
https://issues.apache.org/jira/browse/MESOS-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018317#comment-15018317
]
Marco Massenzio commented on MESOS-3959:
It seems you have made your review request "private"?
Also, did you add the {{mesos}} group to reviewers.
As with other tickets, please make sure you have a shepherd for your changes.
> Executor page of mesos ui does not show slave hostname
> --
>
> Key: MESOS-3959
> URL: https://issues.apache.org/jira/browse/MESOS-3959
> Project: Mesos
> Issue Type: Bug
> Components: webui
>Reporter: Ian Babrou
>
> This is not really convenient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2717) Qemu/KVM containerizer
[ https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned MESOS-2717: -- Assignee: James Peach I'd like to work on this. I have a couple of other Mesos issues to take care of this, but then I'll start putting together a design document. > Qemu/KVM containerizer > -- > > Key: MESOS-2717 > URL: https://issues.apache.org/jira/browse/MESOS-2717 > Project: Mesos > Issue Type: Wish > Components: containerization >Reporter: Pierre-Yves Ritschard >Assignee: James Peach > > I think it would make sense for Mesos to have the ability to treat > hypervisors as containerizers and the most sensible one to start with would > probably be Qemu/KVM. > There are a few workloads that can require full-fledged VMs (the most obvious > one being Windows workloads). > The containerization code is well decoupled and seems simple enough, I can > definitely take a shot at it. VMs do bring some questions with them here is > my take on them: > 1. Routing, network strategy > == > The simplest approach here might very well be to go for bridged networks > and leave the setup and inter slave routing up to the administrator > 2. IP Address assignment > > At first, it can be up to the Frameworks to deal with IP assignment. > The simplest way to address this could be to have an executor running > on slaves providing the qemu/kvm containerizer which would instrument a DHCP > server and collect IP + Mac address resources from slaves. While it may be up > to the frameworks to provide this, an example should most likely be provided. > 3. VM Templates > == > VM templates should probably leverage the fetcher and could thus be copied > locally or fetch from HTTP(s) / HDFS. > 4. Resource limiting > > Mapping resouce constraints to the qemu command line is probably the easiest > part, Additional command line should also be fetchable. For Unix VMs, the > sandbox could show the output of the serial console > 5. Libvirt / plain Qemu > = > I tend to favor limiting the amount of necessary hoops to jump through and > would thus investigate working directly with Qemu, maintaining an open > connection to the monitor to assert status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3952) Prevent use of outdated test-executor Docker image.
[ https://issues.apache.org/jira/browse/MESOS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio reassigned MESOS-3952: -- Assignee: Timothy Chen [~tnachen]: Assigning to you so you can re-assign accordingly, thanks! > Prevent use of outdated test-executor Docker image. > --- > > Key: MESOS-3952 > URL: https://issues.apache.org/jira/browse/MESOS-3952 > Project: Mesos > Issue Type: Improvement >Reporter: Till Toenshoff >Assignee: Timothy Chen > > The test-executor docker image (tnachen/test-executor) contains mesos proto > files / generated go code (mesos-go). We need to make sure that any update on > those protos within mesos does force a Docker pull on this image instead of > relying on an outdated, cached version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
Bernd Mathiske created MESOS-3973:
-
Summary: Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
Key: MESOS-3973
URL: https://issues.apache.org/jira/browse/MESOS-3973
Project: Mesos
Issue Type: Bug
Components: build
Affects Versions: 0.26.0
Environment: Mac OS X 10.10.5, Clang 7.0.0.
Reporter: Bernd Mathiske
Assignee: Gilbert Song
Non-root 'make distcheck.
{noformat}
...
[--] Global test environment tear-down
[==] 826 tests from 113 test cases ran. (276624 ms total)
[ PASSED ] 826 tests.
YOU HAVE 6 DISABLED TESTS
Making install in .
make[3]: Nothing to be done for `install-exec-am'.
../install-sh -c -d
'/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
/usr/bin/install -c -m 644 mesos.pc
'/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
Making install in 3rdparty
/Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
Making install in libprocess
Making install in 3rdparty
/Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
Making install in stout
Making install in .
make[9]: Nothing to be done for `install-exec-am'.
make[9]: Nothing to be done for `install-data-am'.
Making install in include
make[9]: Nothing to be done for `install-exec-am'.
../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
'/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
'/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
/usr/bin/install -c -m 644
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/nothing.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/preprocessor.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/recordio.hpp
../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/result.hpp
'/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
../../../../../../3rdparty/libprocess/3rdpa
[jira] [Commented] (MESOS-3959) Executor page of mesos ui does not show slave hostname
[ https://issues.apache.org/jira/browse/MESOS-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018336#comment-15018336 ] Ian Babrou commented on MESOS-3959: --- Sorry, I don't usually use review tools that require so many useless steps. Made all review requests public. > Executor page of mesos ui does not show slave hostname > -- > > Key: MESOS-3959 > URL: https://issues.apache.org/jira/browse/MESOS-3959 > Project: Mesos > Issue Type: Bug > Components: webui >Reporter: Ian Babrou > > This is not really convenient. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3959) Executor page of mesos ui does not show slave hostname
[
https://issues.apache.org/jira/browse/MESOS-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018346#comment-15018346
]
Marco Massenzio commented on MESOS-3959:
Please consider using {{support/post-reviews.py}} it does all the necessary
steps for you.
> Executor page of mesos ui does not show slave hostname
> --
>
> Key: MESOS-3959
> URL: https://issues.apache.org/jira/browse/MESOS-3959
> Project: Mesos
> Issue Type: Bug
> Components: webui
>Reporter: Ian Babrou
>
> This is not really convenient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3969) Failing 'make distcheck' on Debian 8, somehow SSL-related.
[
https://issues.apache.org/jira/browse/MESOS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018356#comment-15018356
]
Joseph Wu commented on MESOS-3969:
--
This is likely a configuration issue.
Some of the SSL/TLS protocols are not compiled into some versions of
{{openssl}}, which is then linked to cpython, which results in the presence or
lack of some constants. It's unfortunate that {{pip}} is relying on the
existence of {{PROTOCOL_SSLv3}} considering [this
warning|https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_SSLv3].
> Failing 'make distcheck' on Debian 8, somehow SSL-related.
> --
>
> Key: MESOS-3969
> URL: https://issues.apache.org/jira/browse/MESOS-3969
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
> Environment: Debian 8, gcc 4.9.2, Docker 1.9.0, vagrant, libvirt
> Vagrantfile see MESOS-3957
>Reporter: Bernd Mathiske
>Assignee: Joris Van Remoortere
> Labels: build, build-failure, mesosphere
>
> As non-root: make distcheck.
> {noformat}
> /bin/mkdir -p '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> /bin/bash ../libtool --mode=install /usr/bin/install -c mesos-local mesos-log
> mesos mesos-execute mesos-resolve
> '/home/vagrant/mesos/build/mesos-0.26.0/_inst/bin'
> libtool: install: /usr/bin/install -c .libs/mesos-local
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-local
> libtool: install: /usr/bin/install -c .libs/mesos-log
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-log
> libtool: install: /usr/bin/install -c .libs/mesos
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos
> libtool: install: /usr/bin/install -c .libs/mesos-execute
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-execute
> libtool: install: /usr/bin/install -c .libs/mesos-resolve
> /home/vagrant/mesos/build/mesos-0.26.0/_inst/bin/mesos-resolve
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/__init_.py",
> line 11, in
> from pip.vcs import git, mercurial, subversion, bazaar # noqa
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/vcs/mercurial.py",
> line 9, in
> from pip.download import path_to_url
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/download.py",
> line 22, in
> from pip._vendor import requests, six
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/build/3rdparty/pip-1.5.6/pip/_vendor/requests/__init_.py",
> line 53, in
> from .packages.urllib3.contrib import pyopenssl
> File
> "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rdparty/pip-1.5.6/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py",
> line 70, in
> ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
> AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/vagrant/mesos/build/mesos-0.26.0/_build/3rd
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3959) Executor page of mesos ui does not show slave hostname
[ https://issues.apache.org/jira/browse/MESOS-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018360#comment-15018360 ] Ian Babrou commented on MESOS-3959: --- That's what I did. > Executor page of mesos ui does not show slave hostname > -- > > Key: MESOS-3959 > URL: https://issues.apache.org/jira/browse/MESOS-3959 > Project: Mesos > Issue Type: Bug > Components: webui >Reporter: Ian Babrou > > This is not really convenient. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3123) DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
[
https://issues.apache.org/jira/browse/MESOS-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018388#comment-15018388
]
Till Toenshoff commented on MESOS-3123:
---
For the records, I am seeing this failing on the following CentOS 6.7 machine
as well:
{noformat}
cat << EOF > Vagrantfile
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# Disable shared folder to prevent certain kernel module dependencies.
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.hostname = "centos67"
config.vm.box = "bento/centos-6.7"
config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
end
config.vm.provider "vmware_fusion" do |vb|
vb.memory = 9216
vb.cpus = 4
end
config.vm.provision "shell", inline: <<-SHELL
# Kernel 3.10 (required by Docker):
sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
sudo rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm
sudo yum --enablerepo=elrepo-kernel install -y kernel-lt
sudo sed -i "s/default=1/default=0/g" /etc/grub.conf
sudo sed -i "s/default=1/default=0/g" /boot/grub/grub.conf
echo "SELINUX=disabled" > config
echo "SELINUXTYPE=targeted" >> config
sudo mv config /etc/selinux
sudo yum install -y
http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
(cd /etc/yum.repos.d; sudo wget http://www.hop5.in/yum/el6/hop5.repo)
# gcc 4.8 (required by Mesos):
sudo wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O
/etc/yum.repos.d/devtools-2.repo
sudo yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++
# Docker:
sudo wget -qO- https://get.docker.com/ | sh
cp /etc/fstab .
echo "none/sys/fs/cgroup cgroup defaults
0 0" >> fstab
sudo mv fstab /etc/
sudo yum install -y tar wget
sudo wget
http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo
-O /etc/yum.repos.d/epel-apache-maven.repo
sudo yum groupinstall -y "Development Tools"
sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel
zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5
apr-devel subversion-devel apr-util-devel
sudo yum install -y git
sudo docker info
#sudo wget -qO- https://get.docker.com/ | sh
SHELL
end
EOF
vagrant up
vagrant reload
vagrant ssh -c "
scl enable devtoolset-2 bash
git clone https://github.com/apache/mesos.git mesos
cd mesos
git checkout -b 0.26.0-rc1 0.26.0-rc1
./bootstrap
mkdir build
cd build
../configure
make -j4 check
sudo ./bin/mesos-tests.sh
"
{noformat}
> DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged fails & crashes
> ---
>
> Key: MESOS-3123
> URL: https://issues.apache.org/jira/browse/MESOS-3123
> Project: Mesos
> Issue Type: Bug
> Components: docker, test
>Affects Versions: 0.23.0
> Environment: CentOS 7.1, CentOS 6.6, or Ubuntu 14.04
> Mesos 0.23.0-rc4 or today's master
> Docker 1.9
>Reporter: Adam B
>Assignee: Timothy Chen
> Labels: mesosphere
>
> Fails the test and then crashes while trying to shutdown the slaves.
> {code}
> [ RUN ] DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged
> ../../src/tests/docker_containerizer_tests.cpp:618: Failure
> Value of: statusRunning.get().state()
> Actual: TASK_LOST
> Expected: TASK_RUNNING
> ../../src/tests/docker_containerizer_tests.cpp:619: Failure
> Failed to wait 1mins for statusFinished
> ../../src/tests/docker_containerizer_tests.cpp:610: Failure
> Actual function call count doesn't match EXPECT_CALL(sched,
> statusUpdate(&driver, _))...
> Expected: to be called twice
>Actual: called once - unsatisfied and active
> F0721 21:59:54.950773 30622 logging.cpp:57] RAW: Pure virtual method called
> @ 0x7f3915347a02 google::LogMessage::Fail()
> @ 0x7f391534cee4 google::RawLog__()
> @ 0x7f3914890312 __cxa_pure_virtual
> @ 0x88c3ae mesos::internal::tests::Cluster::Slaves::shutdown()
> @ 0x88c176 mesos::internal::tests::Cluster::Slaves::~Slaves()
> @ 0x88dc16 mesos::internal::tests::Cluster::~Cluster()
> @ 0x88dc87 mesos::internal::tests::MesosTest::~MesosTest()
> @ 0xa529ab
> mesos::internal::tests::DockerContainerizerTest::~DockerContainerizerTest()
> @ 0xa8125f
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test()
> @ 0xa8128e
> mesos::internal::tests::DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_Bridged_Test::~DockerCo
[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
[
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018396#comment-15018396
]
Timothy Chen commented on MESOS-3937:
-
You need to run mesos-tests as root since it's a ROOT_DOCKER test.
> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/40AlT8/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master"
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5'
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a
> I1117 15:08:09.296115 26399 master.cpp:1619
[jira] [Commented] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018400#comment-15018400
]
Greg Mann commented on MESOS-3928:
--
We confirmed that
{{DockerContainerizerTest.ROOT_DOCKER_Launch_Executor_Bridged}} does fail in
0.25.0 on Ubuntu 14.04 and CentOS 7.1. Ran {{sudo make distcheck}} after
configuring with SSL and libevent enabled. It does not appear to be a
regression.
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
>Priority: Blocker
> Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3974) CgroupsAnyHierarchyMemoryPressureTest tests fail on CentOS 6.7.
Till Toenshoff created MESOS-3974:
-
Summary: CgroupsAnyHierarchyMemoryPressureTest tests fail on
CentOS 6.7.
Key: MESOS-3974
URL: https://issues.apache.org/jira/browse/MESOS-3974
Project: Mesos
Issue Type: Bug
Affects Versions: 0.26.0
Environment: CentOS 6.7, kernel 2.6.32-573.el6.x86_64, gcc 4.8.2,
docker 1.7.1
Reporter: Till Toenshoff
Assignee: Joris Van Remoortere
{noformat}
GLOG_v=2 sudo ./bin/mesos-tests.sh
--gtest_filter="CgroupsAnyHierarchyMemoryPressureTest.*" --verbose
{noformat}
{noformat}
WARNING: Logging before InitGoogleLogging() is written to STDERR
I1120 17:40:40.410383 2467 process.cpp:2426] Spawned process
__gc__@127.0.0.1:45300
I1120 17:40:40.410909 2467 process.cpp:2426] Spawned process
help@127.0.0.1:45300
I1120 17:40:40.410845 2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300
at 2015-11-20 17:40:40.410562048+00:00
I1120 17:40:40.410970 2467 process.cpp:2426] Spawned process
logging@127.0.0.1:45300
I1120 17:40:40.410995 2467 process.cpp:2426] Spawned process
profiler@127.0.0.1:45300
I1120 17:40:40.411015 2482 process.cpp:2436] Resuming help@127.0.0.1:45300 at
2015-11-20 17:40:40.410989056+00:00
I1120 17:40:40.411063 2467 process.cpp:2426] Spawned process
system@127.0.0.1:45300
I1120 17:40:40.411160 2482 process.cpp:2436] Resuming profiler@127.0.0.1:45300
at 2015-11-20 17:40:40.411155968+00:00
I1120 17:40:40.411206 2467 process.cpp:2426] Spawned process
__limiter__(1)@127.0.0.1:45300
I1120 17:40:40.411223 2467 process.cpp:2426] Spawned process
metrics@127.0.0.1:45300
I1120 17:40:40.411268 2482 process.cpp:2436] Resuming system@127.0.0.1:45300
at 2015-11-20 17:40:40.411266048+00:00
I1120 17:40:40.411378 2483 process.cpp:2436] Resuming
__limiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.411374080+00:00
I1120 17:40:40.411388 2467 process.cpp:2426] Spawned process
__processes__@127.0.0.1:45300
I1120 17:40:40.411399 2483 process.cpp:2436] Resuming
__processes__@127.0.0.1:45300 at 2015-11-20 17:40:40.411397888+00:00
I1120 17:40:40.411402 2467 process.cpp:965] libprocess is initialized on
127.0.0.1:45300 for 8 cpus
I1120 17:40:40.411415 2488 process.cpp:2436] Resuming help@127.0.0.1:45300 at
2015-11-20 17:40:40.411397888+00:00
I1120 17:40:40.411432 2467 logging.cpp:177] Logging to STDERR
I1120 17:40:40.411384 2482 process.cpp:2436] Resuming metrics@127.0.0.1:45300
at 2015-11-20 17:40:40.411379200+00:00
I1120 17:40:40.411717 2482 process.cpp:2436] Resuming help@127.0.0.1:45300 at
2015-11-20 17:40:40.411710976+00:00
I1120 17:40:40.411813 2487 process.cpp:2436] Resuming logging@127.0.0.1:45300
at 2015-11-20 17:40:40.411789056+00:00
I1120 17:40:40.411989 2487 process.cpp:2436] Resuming help@127.0.0.1:45300 at
2015-11-20 17:40:40.411983872+00:00
Source directory: /home/vagrant/mesos
Build directory: /home/vagrant/mesos/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
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
I1120 17:40:40.414676 2467 process.cpp:2426] Spawned process
reaper(1)@127.0.0.1:45300
I1120 17:40:40.414728 2482 process.cpp:2436] Resuming
reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.414701824+00:00
I1120 17:40:40.415870 2467 process.cpp:2426] Spawned process
__latch__(1)@127.0.0.1:45300
I1120 17:40:40.415913 2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300
at 2015-11-20 17:40:40.415889920+00:00
I1120 17:40:40.415966 2467 process.cpp:2426] Spawned process
__waiter__(1)@127.0.0.1:45300
I1120 17:40:40.416054 2483 process.cpp:2436] Resuming
__latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416045056+00:00
I1120 17:40:40.416070 2467 process.cpp:2734] Donating thread to
__waiter__(1)@127.0.0.1:45300 while waiting
I1120 17:40:40.416093 2467 process.cpp:2436] Resuming
__waiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.416083968+00:00
I1120 17:40:40.517282 2483 process.cpp:2436] Resuming
reaper(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.517263872+00:00
I1120 17:40:40.519779 2488 process.cpp:2436] Resuming
__latch__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.519730176+00:00
I1120 17:40:40.519865 2488 process.cpp:2541] Cleaning up
__latch__(1)@127.0.0.1:45300
I1120 17:40:40.520251 2488 process.cpp:2436] Resuming
__waiter__(1)@127.0.0.1:45300 at 2015-11-20 17:40:40.520241920+00:00
I1120 17:40:40.520292 2483 process.cpp:2436] Resuming __gc__@127.0.0.1:45300
at 2015-11-20 17:40:40.520276992+00:00
I1120 17:40:40.520308 2488 process.cpp:2541] Cleaning up
__waiter__(1)@127.0.0.1:45300
sh: perf: command not found
[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
[
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018416#comment-15018416
]
Bernd Mathiske commented on MESOS-3937:
---
Sorry, forgot to write the sudo in the text above, but when I ran the test I
typed it.
> Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
> ---
>
> Key: MESOS-3937
> URL: https://issues.apache.org/jira/browse/MESOS-3937
> Project: Mesos
> Issue Type: Bug
> Components: docker
>Affects Versions: 0.26.0
> Environment: Ubuntu 14.04, gcc 4.8.4, Docker version 1.6.2
> 8 CPUs, 16 GB memory
> Vagrant, libvirt/Virtual Box or VMware
>Reporter: Bernd Mathiske
>Assignee: Timothy Chen
>
> {noformat}
> ../configure
> make check
> sudo ./bin/mesos-tests.sh
> --gtest_filter="DockerContainerizerTest.ROOT_DOCKER_Launch_Executor" --verbose
> {noformat}
> {noformat}
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from DockerContainerizerTest
> I1117 15:08:09.265943 26380 leveldb.cpp:176] Opened db in 3.199666ms
> I1117 15:08:09.267761 26380 leveldb.cpp:183] Compacted db in 1.684873ms
> I1117 15:08:09.267902 26380 leveldb.cpp:198] Created db iterator in 58313ns
> I1117 15:08:09.267966 26380 leveldb.cpp:204] Seeked to beginning of db in
> 4927ns
> I1117 15:08:09.267997 26380 leveldb.cpp:273] Iterated through 0 keys in the
> db in 1605ns
> I1117 15:08:09.268156 26380 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1117 15:08:09.270148 26396 recover.cpp:449] Starting replica recovery
> I1117 15:08:09.272105 26396 recover.cpp:475] Replica is in EMPTY status
> I1117 15:08:09.275640 26396 replica.cpp:676] Replica in EMPTY status received
> a broadcasted recover request from (4)@10.0.2.15:50088
> I1117 15:08:09.276578 26399 recover.cpp:195] Received a recover response from
> a replica in EMPTY status
> I1117 15:08:09.277600 26397 recover.cpp:566] Updating replica status to
> STARTING
> I1117 15:08:09.279613 26396 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.016098ms
> I1117 15:08:09.279731 26396 replica.cpp:323] Persisted replica status to
> STARTING
> I1117 15:08:09.280306 26399 recover.cpp:475] Replica is in STARTING status
> I1117 15:08:09.282181 26400 replica.cpp:676] Replica in STARTING status
> received a broadcasted recover request from (5)@10.0.2.15:50088
> I1117 15:08:09.282552 26400 master.cpp:367] Master
> 59c600f1-92ff-4926-9c84-073d9b81f68a (vagrant-ubuntu-trusty-64) started on
> 10.0.2.15:50088
> I1117 15:08:09.283021 26400 master.cpp:369] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_slaves="true" --authenticators="crammd5"
> --authorizers="local" --credentials="/tmp/40AlT8/credentials"
> --framework_sorter="drf" --help="false" --hostname_lookup="true"
> --initialize_driver_logging="true" --log_auto_initialize="true"
> --logbufsecs="0" --logging_level="INFO" --max_slave_ping_timeouts="5"
> --quiet="false" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="25secs" --registry_strict="true"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/usr/local/share/mesos/webui" --work_dir="/tmp/40AlT8/master"
> --zk_session_timeout="10secs"
> I1117 15:08:09.283920 26400 master.cpp:414] Master only allowing
> authenticated frameworks to register
> I1117 15:08:09.283972 26400 master.cpp:419] Master only allowing
> authenticated slaves to register
> I1117 15:08:09.284032 26400 credentials.hpp:37] Loading credentials for
> authentication from '/tmp/40AlT8/credentials'
> I1117 15:08:09.282944 26401 recover.cpp:195] Received a recover response from
> a replica in STARTING status
> I1117 15:08:09.284639 26401 recover.cpp:566] Updating replica status to VOTING
> I1117 15:08:09.285539 26400 master.cpp:458] Using default 'crammd5'
> authenticator
> I1117 15:08:09.285995 26401 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 1.075466ms
> I1117 15:08:09.286062 26401 replica.cpp:323] Persisted replica status to
> VOTING
> I1117 15:08:09.286200 26401 recover.cpp:580] Successfully joined the Paxos
> group
> I1117 15:08:09.286471 26401 recover.cpp:464] Recover process terminated
> I1117 15:08:09.287303 26400 authenticator.cpp:520] Initializing server SASL
> I1117 15:08:09.289371 26400 master.cpp:495] Authorization enabled
> I1117 15:08:09.296018 26399 master.cpp:1606] The newly elected leader is
> master@10.0.2.15:50088 with id 59c600f1-92ff-4926-9c84-073d9b81f68a
> I1117 15:08:09.296
[jira] [Commented] (MESOS-3608) optionally install test binaries
[
https://issues.apache.org/jira/browse/MESOS-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018521#comment-15018521
]
James Peach commented on MESOS-3608:
Hey [~tillt], I posted https://reviews.apache.org/r/40553/, which depends on
MESOS-3725.
This turned out to be a bit more involved that I had expected due to the number
of tests that exec or dlopen various tools. I have some concerns about how
maintainable this will be into the future. The current status is that some of
the tests fail due to various shell scripts expecting to be run from the build
directory, but I wanted to get this out and get your comments and review.
Thanks.
> optionally install test binaries
>
>
> Key: MESOS-3608
> URL: https://issues.apache.org/jira/browse/MESOS-3608
> Project: Mesos
> Issue Type: Improvement
> Components: build, test
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
>
> Many of the tests in Mesos could be described as integration tests, since
> they have external dependencies on kernel features, installed tools,
> permissions, etc. I'd like to be able to generate a {{mesos-tests}} RPM along
> with my {{mesos}} RPM so that I can run the same tests in different
> deployment environments.
> I propose a new configuration option named {{--enable-test-tools}} that will
> install the tests into {{libexec/mesos/tests}}. I'll also need to make some
> minor changes to tests so that helper tools can be found in this location as
> well as in the build directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3975) SSL build of mesos causes flaky testsuite.
Till Toenshoff created MESOS-3975:
-
Summary: SSL build of mesos causes flaky testsuite.
Key: MESOS-3975
URL: https://issues.apache.org/jira/browse/MESOS-3975
Project: Mesos
Issue Type: Bug
Affects Versions: 0.26.0
Environment: CentOS 7.1, Kernel 3.10.0-229.20.1.el7.x86_64, gcc 4.8.3,
Docker 1.9
Reporter: Till Toenshoff
Assignee: Joris Van Remoortere
When running the tests of an SSL build of Mesos on CentOS 7.1, I see spurious
test failures that are, so far, not reproducible.
The following tests did fail for me in complete runs but did seem fine when
running them individually, in repetition.
{noformat}
DockerTest.ROOT_DOCKER_CheckPortResource
{noformat}
{noformat}
ContainerizerTest.ROOT_CGROUPS_BalloonFramework
{noformat}
{noformat}
[ RUN ]
LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystemCommandExecutor
2015-11-20
19:08:38,826:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
+ /home/vagrant/mesos/build/src/mesos-containerizer mount --help=false
--operation=make-rslave --path=/
+ grep -E
/tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/.+
/proc/self/mountinfo
+ grep -v 2b98025c-74f1-41d2-b35a-ce2cdfae347e
+ cut '-d ' -f5
+ xargs --no-run-if-empty umount -l
+ mount -n --rbind
/tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/provisioner/containers/2b98025c-74f1-41d2-b35a-ce2cdfae347e/backends/copy/rootfses/bed11080-474b-4c69-8e7f-0ab85e895b0d
/tmp/LinuxFilesystemIsolatorTest_ROOT_ChangeRootFilesystemCommandExecutor_Tz7P8c/slaves/830e842e-c36a-4e4c-bff4-5b9568d7df12-S0/frameworks/830e842e-c36a-4e4c-bff4-5b9568d7df12-/executors/c735be54-c47f-4645-bfc1-2f4647e2cddb/runs/2b98025c-74f1-41d2-b35a-ce2cdfae347e/.rootfs
Could not load cert file
../../src/tests/containerizer/filesystem_isolator_tests.cpp:354: Failure
Value of: statusRunning.get().state()
Actual: TASK_FAILED
Expected: TASK_RUNNING
2015-11-20
19:08:42,164:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-11-20
19:08:45,501:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-11-20
19:08:48,837:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-11-20
19:08:52,174:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
../../src/tests/containerizer/filesystem_isolator_tests.cpp:355: Failure
Failed to wait 15secs for statusFinished
../../src/tests/containerizer/filesystem_isolator_tests.cpp:349: Failure
Actual function call count doesn't match EXPECT_CALL(sched,
statusUpdate(&driver, _))...
Expected: to be called twice
Actual: called once - unsatisfied and active
2015-11-20
19:08:55,511:21380(0x7fa10d5f2700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:53444] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
*** Aborted at 1448046536 (unix time) try "date -d @1448046536" if you are
using GNU date ***
PC: @0x0 (unknown)
*** SIGSEGV (@0x0) received by PID 21380 (TID 0x7fa1549e68c0) from PID 0; stack
trace: ***
@ 0x7fa141796fbb (unknown)
@ 0x7fa14179b341 (unknown)
@ 0x7fa14f096130 (unknown)
{noformat}
Vagrantfile generator:
{noformat}
cat << EOF > Vagrantfile
# -*- mode: ruby -*-" >
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# Disable shared folder to prevent certain kernel module dependencies.
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.hostname = "centos71"
config.vm.box = "bento/centos-7.1"
config.vm.provider "virtualbox" do |vb|
vb.memory = 16384
vb.cpus = 8
end
config.vm.provider "vmware_fusion" do |vb|
vb.memory = 9216
vb.cpus = 4
end
config.vm.provision "shell", inline: <<-SHELL
sudo yum -y update systemd
sudo yum install -y tar wget
sudo wget
http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo
-O /etc/yum.repos.d/epel-apache-maven.repo
sudo yum groupinstall -y "Development Tools"
sudo yum install -y apache-maven python-devel java-1.7.0-openjdk-devel
zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5
apr-devel subversion-devel apr-util-devel
sudo yum install libevent-devel
sudo yum install -y git
sudo yum install -y docker
sudo serv
[jira] [Updated] (MESOS-3753) Test the HTTP Scheduler library with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Wu updated MESOS-3753: - Assignee: Anand Mazumdar (was: Joseph Wu) Assigning to [~anandmazumdar]. Here is the basic pattern for testing with different SSL configurations: https://reviews.apache.org/r/40513/ You should add more tests (and possibly fix the underlying library) as necessary. > Test the HTTP Scheduler library with SSL enabled > > > Key: MESOS-3753 > URL: https://issues.apache.org/jira/browse/MESOS-3753 > Project: Mesos > Issue Type: Story > Components: framework, HTTP API, test >Reporter: Joseph Wu >Assignee: Anand Mazumdar > Labels: mesosphere, security > > Currently, the HTTP Scheduler library does not support SSL-enabled Mesos. > (You can manually test this by spinning up an SSL-enabled master and attempt > to run the event-call framework example against it.) > We need to add tests that check the HTTP Scheduler library against > SSL-enabled Mesos: > * with downgrade support, > * with required framework/client-side certifications, > * with/without verification of certificates (master-side), > * with/without verification of certificates (framework-side), > * with a custom certificate authority (CA) > These options should be controlled by the same environment variables found on > the [SSL user doc|http://mesos.apache.org/documentation/latest/ssl/]. > Note: This issue will be broken down into smaller sub-issues as bugs/problems > are discovered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3976) HTTP Scheduler Library does not work with SSL enabled
Joseph Wu created MESOS-3976: Summary: HTTP Scheduler Library does not work with SSL enabled Key: MESOS-3976 URL: https://issues.apache.org/jira/browse/MESOS-3976 Project: Mesos Issue Type: Bug Components: framework, HTTP API Reporter: Joseph Wu Assignee: Anand Mazumdar The HTTP scheduler library does not work against Mesos when SSL is enabled (without downgrade). The fix should be simple: * The library should detect if SSL is enabled. * If SSL is enabled, connections should be made with HTTPS instead of HTTP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3976) C++ HTTP Scheduler Library does not work with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-3976: -- Summary: C++ HTTP Scheduler Library does not work with SSL enabled (was: HTTP Scheduler Library does not work with SSL enabled) > C++ HTTP Scheduler Library does not work with SSL enabled > - > > Key: MESOS-3976 > URL: https://issues.apache.org/jira/browse/MESOS-3976 > Project: Mesos > Issue Type: Bug > Components: framework, HTTP API >Reporter: Joseph Wu >Assignee: Anand Mazumdar > Labels: mesosphere, security > > The HTTP scheduler library does not work against Mesos when SSL is enabled > (without downgrade). > The fix should be simple: > * The library should detect if SSL is enabled. > * If SSL is enabled, connections should be made with HTTPS instead of HTTP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3976) C++ HTTP Scheduler Library does not work with SSL enabled
[ https://issues.apache.org/jira/browse/MESOS-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand Mazumdar updated MESOS-3976: -- Description: The C++ HTTP scheduler library does not work against Mesos when SSL is enabled (without downgrade). The fix should be simple: * The library should detect if SSL is enabled. * If SSL is enabled, connections should be made with HTTPS instead of HTTP. was: The HTTP scheduler library does not work against Mesos when SSL is enabled (without downgrade). The fix should be simple: * The library should detect if SSL is enabled. * If SSL is enabled, connections should be made with HTTPS instead of HTTP. > C++ HTTP Scheduler Library does not work with SSL enabled > - > > Key: MESOS-3976 > URL: https://issues.apache.org/jira/browse/MESOS-3976 > Project: Mesos > Issue Type: Bug > Components: framework, HTTP API >Reporter: Joseph Wu >Assignee: Anand Mazumdar > Labels: mesosphere, security > > The C++ HTTP scheduler library does not work against Mesos when SSL is > enabled (without downgrade). > The fix should be simple: > * The library should detect if SSL is enabled. > * If SSL is enabled, connections should be made with HTTPS instead of HTTP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3794) Master should not store arbitrarily sized data in ExecutorInfo
[
https://issues.apache.org/jira/browse/MESOS-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-3794:
-
Assignee: (was: Joseph Wu)
> Master should not store arbitrarily sized data in ExecutorInfo
> --
>
> Key: MESOS-3794
> URL: https://issues.apache.org/jira/browse/MESOS-3794
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Joseph Wu
>Priority: Critical
> Labels: mesosphere
>
> From a comment in [MESOS-3771]:
> Master should not be storing the {{data}} fields from {{ExecutorInfo}}. We
> currently [store the entire
> object|https://github.com/apache/mesos/blob/master/src/master/master.hpp#L262-L271],
> which means master would be at high risk of OOM-ing if a bunch of executors
> were started with big {{data}} blobs.
> * Master should scrub out unneeded bloat from {{ExecutorInfo}} before storing
> it.
> * We can use an alternate internal object, like we do for {{TaskInfo}} vs
> {{Task}}; see
> [this|https://github.com/apache/mesos/blob/master/src/messages/messages.proto#L39-L41].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
[
https://issues.apache.org/jira/browse/MESOS-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018724#comment-15018724
]
Gilbert Song commented on MESOS-3973:
-
It is not a regression from 0.25. `make distcheck` is also failing in 0.25.0 on
OS X 10.10.5, because files like `/lib/python/site-packages/mesos/__init__.py`
are not removed. It passed in ubuntu14.04, which means that `cd && rm -f` is
working on a correct directory. Still figuring out why this failed on OS X.
> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Assignee: Gilbert Song
> Labels: build, build-failure, mesosphere
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [ PASSED ] 826 tests.
> YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
> ../install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> /usr/bin/install -c -m 644 mesos.pc
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
> ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
> ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
> /usr/bin/install -c -m 644
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/nothing.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp
> .
[jira] [Commented] (MESOS-3794) Master should not store arbitrarily sized data in ExecutorInfo
[
https://issues.apache.org/jira/browse/MESOS-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018726#comment-15018726
]
James Peach commented on MESOS-3794:
I have a need to pass largish blobs through ExecutorInfo. I would be happy to
take this ticket if that is OK.
> Master should not store arbitrarily sized data in ExecutorInfo
> --
>
> Key: MESOS-3794
> URL: https://issues.apache.org/jira/browse/MESOS-3794
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Joseph Wu
>Priority: Critical
> Labels: mesosphere
>
> From a comment in [MESOS-3771]:
> Master should not be storing the {{data}} fields from {{ExecutorInfo}}. We
> currently [store the entire
> object|https://github.com/apache/mesos/blob/master/src/master/master.hpp#L262-L271],
> which means master would be at high risk of OOM-ing if a bunch of executors
> were started with big {{data}} blobs.
> * Master should scrub out unneeded bloat from {{ExecutorInfo}} before storing
> it.
> * We can use an alternate internal object, like we do for {{TaskInfo}} vs
> {{Task}}; see
> [this|https://github.com/apache/mesos/blob/master/src/messages/messages.proto#L39-L41].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3794) Master should not store arbitrarily sized data in ExecutorInfo
[
https://issues.apache.org/jira/browse/MESOS-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018776#comment-15018776
]
Joseph Wu commented on MESOS-3794:
--
That would be appreciated.
> Master should not store arbitrarily sized data in ExecutorInfo
> --
>
> Key: MESOS-3794
> URL: https://issues.apache.org/jira/browse/MESOS-3794
> Project: Mesos
> Issue Type: Bug
> Components: master
>Reporter: Joseph Wu
>Priority: Critical
> Labels: mesosphere
>
> From a comment in [MESOS-3771]:
> Master should not be storing the {{data}} fields from {{ExecutorInfo}}. We
> currently [store the entire
> object|https://github.com/apache/mesos/blob/master/src/master/master.hpp#L262-L271],
> which means master would be at high risk of OOM-ing if a bunch of executors
> were started with big {{data}} blobs.
> * Master should scrub out unneeded bloat from {{ExecutorInfo}} before storing
> it.
> * We can use an alternate internal object, like we do for {{TaskInfo}} vs
> {{Task}}; see
> [this|https://github.com/apache/mesos/blob/master/src/messages/messages.proto#L39-L41].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3928:
---
Priority: Major (was: Blocker)
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
> Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3928:
---
Target Version/s: 0.27.0 (was: 0.26.0)
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
> Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3928:
---
Sprint: Mesosphere Sprint 23 (was: Mesosphere Sprint 22)
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
> Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3928) ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
[
https://issues.apache.org/jira/browse/MESOS-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018881#comment-15018881
]
Marco Massenzio commented on MESOS-3928:
Thanks, [~greggomann] for the investigation.
I've removed it as a blocker for {{0.26}} and targeted it to be fixed for the
{{0.27}} release.
If anyone disagrees, please let us now.
> ROOT tests fail on Mesos 0.26 on Ubuntu/CentOS
> --
>
> Key: MESOS-3928
> URL: https://issues.apache.org/jira/browse/MESOS-3928
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: Marco Massenzio
>Assignee: Greg Mann
> Labels: tech-debt, testing
> Attachments: ROOT-tests-centos-7.1.log, ROOT-tests-ubuntu-14.04.log
>
>
> Running {{0.26.0-rc1}} on both CentOS 7.1 and Ubuntu 14.04 with {{sudo}}
> privileges, causes segfaults when running Docker tests.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3977) http::_operation() creates unnecessary filter, rescinds unnecessarily
Neil Conway created MESOS-3977: -- Summary: http::_operation() creates unnecessary filter, rescinds unnecessarily Key: MESOS-3977 URL: https://issues.apache.org/jira/browse/MESOS-3977 Project: Mesos Issue Type: Bug Reporter: Neil Conway Priority: Minor This function is used by the /reserve, /unreserve, /create-volume, and /destroy-volume endpoints. It has a few worts: 1. It installs a 5-second filter when rescinding an offer. However, the cluster state might change so that the filter is actually undesirable. For example, this scenario: * Create DR, make offer * Create PV => rescinds previous offer, sets filter, makes offer * Destroy PV => rescinds previous offer After the last step, we'll wait 5 seconds for the filter to expire before re-offering the DR. 2. If there are sufficient available resources at the target slave, we don't actually need to rescind any offers in the first place. However, _operation() rescinds offers unconditionally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3937) Test DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails.
[
https://issues.apache.org/jira/browse/MESOS-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018922#comment-15018922
]
Jojy Varghese commented on MESOS-3937:
--
Ran the test on Ubuntu 14.04/vagrant-ubuntu-trusty-64 3.13.0-68-generic/mesos
0.25/ . Had similar results:
{code}
I1120 22:14:31.211333 16846 master.cpp:3248] Launching task 1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- (default) at
scheduler-feee8846-7034-4fa4-8376-c42ca90fd83d@10.0.2.15:39850 with resources
cpus(*):2; mem(*):1024; disk(*):1024; ports(*):[31000-32000] on slave
a713297c-bce5-4207-ae08-b8b5d472f49b-S0 at slave(1)@10.0.2.15:39850
(vagrant-ubuntu-trusty-64)
I1120 22:14:31.211766 16851 slave.cpp:1270] Got assigned task 1 for framework
a713297c-bce5-4207-ae08-b8b5d472f49b-
I1120 22:14:31.212445 16851 slave.cpp:1386] Launching task 1 for framework
a713297c-bce5-4207-ae08-b8b5d472f49b-
I1120 22:14:31.217005 16851 slave.cpp:4852] Launching executor e1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- with resources in work directory
'/tmp/DockerContainerizerTest_ROOT_DOCKER_Launch_Executor_F9qB7N/slaves/a713297c-bce5-4207-ae08-b8b5d472f49b-S0/frameworks/a713297c-bce5-4207-ae08-b8b5d472f49b-/executors/e1/runs/cd453018-9d0b-49b7-a5a7-5e841b3255d9'
I1120 22:14:31.219130 16851 slave.cpp:1604] Queuing task '1' for executor e1 of
framework 'a713297c-bce5-4207-ae08-b8b5d472f49b-
I1120 22:14:31.220677 16849 docker.cpp:766] Starting container
'cd453018-9d0b-49b7-a5a7-5e841b3255d9' for executor 'e1' and framework
'a713297c-bce5-4207-ae08-b8b5d472f49b-'
E1120 22:14:31.810605 16849 slave.cpp:3342] Container
'cd453018-9d0b-49b7-a5a7-5e841b3255d9' for executor 'e1' of framework
'a713297c-bce5-4207-ae08-b8b5d472f49b-' failed to start: Container exited
on error: exited with status 255
I1120 22:14:31.811228 16853 slave.cpp:3433] Executor 'e1' of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- has terminated with unknown status
I1120 22:14:31.812888 16853 slave.cpp:2717] Handling status update TASK_FAILED
(UUID: 1c1f7bb8-4f9a-4757-b1ca-1c689e2d0fcb) for task 1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- from @0.0.0.0:0
W1120 22:14:31.813551 16847 docker.cpp:1002] Ignoring updating unknown
container: cd453018-9d0b-49b7-a5a7-5e841b3255d9
I1120 22:14:31.813796 16853 master.cpp:4508] Executor e1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- on slave
a713297c-bce5-4207-ae08-b8b5d472f49b-S0 at slave(1)@10.0.2.15:39850
(vagrant-ubuntu-trusty-64): terminated with signal Unknown signal 127
I1120 22:14:31.813849 16853 master.cpp:6178] Removing executor 'e1' with
resources of framework a713297c-bce5-4207-ae08-b8b5d472f49b- on slave
a713297c-bce5-4207-ae08-b8b5d472f49b-S0 at slave(1)@10.0.2.15:39850
(vagrant-ubuntu-trusty-64)
I1120 22:14:31.814128 16847 status_update_manager.cpp:322] Received status
update TASK_FAILED (UUID: 1c1f7bb8-4f9a-4757-b1ca-1c689e2d0fcb) for task 1 of
framework a713297c-bce5-4207-ae08-b8b5d472f49b-
I1120 22:14:31.814841 16852 slave.cpp:3016] Forwarding the update TASK_FAILED
(UUID: 1c1f7bb8-4f9a-4757-b1ca-1c689e2d0fcb) for task 1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- to master@10.0.2.15:39850
I1120 22:14:31.815209 16852 master.cpp:4415] Status update TASK_FAILED (UUID:
1c1f7bb8-4f9a-4757-b1ca-1c689e2d0fcb) for task 1 of framework
a713297c-bce5-4207-ae08-b8b5d472f49b- from slave
a713297c-bce5-4207-ae08-b8b5d472f49b-S0 at slave(1)@10.0.2.15:39850
(vagrant-ubuntu-trusty-64)
I1120 22:14:31.815276 16852 master.cpp:4454] Forwarding status update
TASK_FAILED (UUID: 1c1f7bb8-4f9a-4757-b1ca-1c689e2d0fcb) for task 1 of
framework a713297c-bce5-4207-ae08-b8b5d472f49b-
I1120 22:14:31.815479 16852 master.cpp:6081] Updating the latest state of task
1 of framework a713297c-bce5-4207-ae08-b8b5d472f49b- to TASK_FAILED
I1120 22:14:31.816187 16848 hierarchical.hpp:1103] Recovered cpus(*):2;
mem(*):1024; disk(*):1024; ports(*):[31000-32000] (total: cpus(*):2;
mem(*):1024; disk(*):1024; ports(*):[31000-32000], allocated: ) on slave
a713297c-bce5-4207-ae08-b8b5d472f49b-S0 from framework
a713297c-bce5-4207-ae08-b8b5d472f49b-
../../src/tests/containerizer/docker_containerizer_tests.cpp:254: Failure
Value of: statusRunning.get().state()
Actual: TASK_FAILED
Expected: TASK_RUNNING
I1120 22:14:31.816408 16852 master
{code}
stderr for the run shows:
{code}
Warning: '-c' is deprecated, it will be replaced by '--cpu-shares' soon. See
usage.
WARNING: Your kernel does not support swap limit capabilities, memory limited
without swap.
F1120 22:18:10.410233 5 node.go:18] Couldn't determine hostname: exit
status 1
goroutine 1 [running]:
github.com/golang/glog.stacks(0xc20803b400, 0x0, 0x0, 0x0)
/home/tnachen/go/src/github.com/golang/glog/glog.go:726 +0xcd
github.com/golang/glog.(*loggingT).output(0xa95fa0, 0xc20003, 0xc
[jira] [Commented] (MESOS-3951) Make HDFS tool wrappers asynchronous.
[ https://issues.apache.org/jira/browse/MESOS-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018961#comment-15018961 ] Jie Yu commented on MESOS-3951: --- Cleanup patches: commit 1aaf1c3c98e6da68372f7fb761a356fb4219b20d Author: Jie Yu Date: Thu Nov 19 12:21:13 2015 -0800 Used factory method to create HDFS client. Review: https://reviews.apache.org/r/40498 commit d6781a4e9a4f361a98e50980d3ed0a6ab4350208 Author: Jie Yu Date: Wed Nov 18 16:03:30 2015 -0800 Fixed a few style issues in HDFS wrapper code. Review: https://reviews.apache.org/r/40464 commit 5749b80c1452bcdb8e972d162dfe2d1096109c5e Author: Jie Yu Date: Wed Nov 18 15:55:50 2015 -0800 Moved HDFS wrapper implementation to a cpp file. Review: https://reviews.apache.org/r/40463 commit 9c231b2b1551b15d2ca805c193bba7df2f8dfc39 Author: Jie Yu Date: Wed Nov 18 15:30:11 2015 -0800 Fixed the license header in hdfs.hpp. Review: https://reviews.apache.org/r/40462 commit fefb79f4bb9b94da66a27f30958ed96440510b5a Author: Jie Yu Date: Wed Nov 18 15:28:57 2015 -0800 Changed HDFS wrapper from a struct to a class. Review: https://reviews.apache.org/r/40461 > Make HDFS tool wrappers asynchronous. > - > > Key: MESOS-3951 > URL: https://issues.apache.org/jira/browse/MESOS-3951 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu > > The existing HDFS tool wrappers (src/hdfs/hdfs.hpp) are synchronous. They use > os::shell to shell out the 'hadoop' commands. This makes it very hard to be > reused at other locations in the code base. > The URI fetcher HDFS plugin will try to re-use the existing HDFS tool > wrappers. In order to do that, we need to make it asynchronous first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3951) Make HDFS tool wrappers asynchronous.
[ https://issues.apache.org/jira/browse/MESOS-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu reassigned MESOS-3951: - Assignee: Jie Yu > Make HDFS tool wrappers asynchronous. > - > > Key: MESOS-3951 > URL: https://issues.apache.org/jira/browse/MESOS-3951 > Project: Mesos > Issue Type: Task >Reporter: Jie Yu >Assignee: Jie Yu > > The existing HDFS tool wrappers (src/hdfs/hdfs.hpp) are synchronous. They use > os::shell to shell out the 'hadoop' commands. This makes it very hard to be > reused at other locations in the code base. > The URI fetcher HDFS plugin will try to re-use the existing HDFS tool > wrappers. In order to do that, we need to make it asynchronous first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
[
https://issues.apache.org/jira/browse/MESOS-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019052#comment-15019052
]
Gilbert Song commented on MESOS-3973:
-
Note: also failing on 0.23, 0.24.
> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Assignee: Gilbert Song
> Labels: build, build-failure, mesosphere
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [ PASSED ] 826 tests.
> YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
> ../install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> /usr/bin/install -c -m 644 mesos.pc
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
> ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
> ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
> /usr/bin/install -c -m 644
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/nothing.hpp
>
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp
> ../../../../../../3rdparty/libprocess/3rdparty
[jira] [Updated] (MESOS-2533) Support HTTP checks in Mesos health check program
[ https://issues.apache.org/jira/browse/MESOS-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2533: -- Labels: mesosphere (was: ) > Support HTTP checks in Mesos health check program > - > > Key: MESOS-2533 > URL: https://issues.apache.org/jira/browse/MESOS-2533 > Project: Mesos > Issue Type: Bug >Reporter: Niklas Quarfot Nielsen >Assignee: haosdent > Labels: mesosphere > > Currently, only commands are supported but our health check protobuf enables > users to encode HTTP checks as well. We should wire up this in the health > check program or remove the http field from the protobuf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3935) mesos-master crashes when a scheduler with an unresolvable hostname attempts to connect
[
https://issues.apache.org/jira/browse/MESOS-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019134#comment-15019134
]
Hamza Faran commented on MESOS-3935:
Yup, I looked at the source more closely and this was indeed failing on the
lookup of the master's hostname. It was only triggered when a new scheduler
tried to connect however, so that's why I mistakenly assumed it was the other
hostname it was failing to look up.
Alleviated the issue by passing in a hostname using {code}--hostname{code} for
now.
> mesos-master crashes when a scheduler with an unresolvable hostname attempts
> to connect
> ---
>
> Key: MESOS-3935
> URL: https://issues.apache.org/jira/browse/MESOS-3935
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.25.0
>Reporter: Hamza Faran
>
> {code}
> $ sudo mesos-master --ip=10.8.0.5 --work_dir=work_dir --authenticate
> --authenticate_slaves --credentials=credentials --port=5045
>
> I1117 07:05:15.371150 5852 main.cpp:229] Build: 2015-10-12 21:00:09 by root
>
>
> I1117 07:05:15.371314 5852 main.cpp:231] Version: 0.25.0
>
>
> I1117 07:05:15.371340 5852 main.cpp:234] Git tag: 0.25.0
>
>
> I1117 07:05:15.371366 5852 main.cpp:238] Git SHA:
> 2dd7f7ee115fe00b8e098b0a10762a4fa8f4600f
>
>
> I1117 07:05:15.371439 5852 main.cpp:252] Using 'HierarchicalDRF' allocator
>
>
> I1117 07:05:15.373845 5852 leveldb.cpp:176] Opened db in 2.267831ms
>
>
> I1117 07:05:15.374606 5852 leveldb.cpp:183] Compacted db in 678911ns
>
>
> I1117 07:05:15.374668 5852 leveldb.cpp:198] Created db iterator in 19310ns
>
>
> I1117 07:05:15.374775 5852 leveldb.cpp:204] Seeked to beginning of db in
> 79269ns
>
> I1117 07:05:15.374882 5852 leveldb.cpp:273] Iterated through 3 keys in the
> db in 79949ns
>
> I1117 07:05:15.374953 5852 replica.cpp:744] Replica recovered with log
> positions 91 -> 92 with 0 holes and 0 unlearned
>
> I1117 07:05:15.375820 5852 main.cpp:465] Starting Mesos master
>
>
> I1117 07:05:15.376049 5856 recover.cpp:449] Starting replica recovery
>
>
> I1117 07:05:15.376188 5858 recover.cpp:475] Replica is in VOTING status
>
>
> I1117 07:05:15.376332 5858 recover.cpp:464] Recover process terminated
>
>
> F1117 07:05:43.398336 5852 master.cpp:330] Failed to get hostname: Temporary
> failure in name resolution
>
> *** Check failure stack trace: ***
>
>
> @ 0x7f55ebf4273
[jira] [Commented] (MESOS-3786) Backticks are not mentioned in Mesos C++ Style Guide
[
https://issues.apache.org/jira/browse/MESOS-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019239#comment-15019239
]
Timothy Chen commented on MESOS-3786:
-
commit 7e81e50dfac7309b9d75040c353e40ebed2f2ae0
Author: Greg Mann
Date: Fri Nov 20 17:04:49 2015 -0800
Added backtick usage in comments to the C++ style guide.
Review: https://reviews.apache.org/r/40367
> Backticks are not mentioned in Mesos C++ Style Guide
>
>
> Key: MESOS-3786
> URL: https://issues.apache.org/jira/browse/MESOS-3786
> Project: Mesos
> Issue Type: Documentation
>Reporter: Greg Mann
>Assignee: Greg Mann
>Priority: Minor
> Labels: documentation, mesosphere
>
> As far as I can tell, current practice is to quote code excerpts and object
> names with backticks when writing comments. For example:
> {code}
> // You know, `sadPanda` seems extra sad lately.
> std::string sadPanda;
> sadPanda = " :'( ";
> {code}
> However, I don't see this documented in our C++ style guide at all. It should
> be added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3892) Add a helper function to the Agent to retrieve the list of executors that are using optimistically offered, revocable resources.
[
https://issues.apache.org/jira/browse/MESOS-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma reassigned MESOS-3892:
---
Assignee: Klaus Ma (was: Artem Harutyunyan)
> Add a helper function to the Agent to retrieve the list of executors that are
> using optimistically offered, revocable resources.
>
>
> Key: MESOS-3892
> URL: https://issues.apache.org/jira/browse/MESOS-3892
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Klaus Ma
> Labels: mesosphere
>
> {noformat}
> class Slave {
> ...
> // How the master currently keeps track of executors.
> hashmap> executors;
> ...
> // Returns the list of executors that are using optimistically-
> // offered, revocable resources.
> list getEvictableExecutors() { ... }
> ...
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3888) Support distinguishing revocable resources in the Resource protobuf.
[
https://issues.apache.org/jira/browse/MESOS-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3888:
Description:
Add enum type into RevocableInfo:
* Framework need to assign RevocableInfo when launching task; if it’s not
assign, use reserved resources. Framework need to identify which resources it’s
using
* Oversubscription resources need to assign the type by Agent (MESOS-3930)
* Update Oversubscription document that OO has over-subscribe the Allocation
Slack and recommend QoS to handle the usage slack only. (MESOS-3889)
{code}
message Resource {
...
message RevocableInfo {
enum Type {
// Under-utilized, allocated resources. Controlled by
// oversubscription (QoSController & ResourceEstimator).
USAGE_SLACK = 1;
// Unallocated, reserved resources.
// Controlled by optimistic offers (Allocator).
ALLOCATION_SLACK = 2;
}
required Type type = 1;
}
...
optional RevocableInfo revocable = 9;
}
{code}
was:We need to distinguish revocable resource for usage slack and allocation
slack.
> Support distinguishing revocable resources in the Resource protobuf.
>
>
> Key: MESOS-3888
> URL: https://issues.apache.org/jira/browse/MESOS-3888
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Klaus Ma
> Labels: mesosphere
>
> Add enum type into RevocableInfo:
> * Framework need to assign RevocableInfo when launching task; if it’s not
> assign, use reserved resources. Framework need to identify which resources
> it’s using
> * Oversubscription resources need to assign the type by Agent (MESOS-3930)
> * Update Oversubscription document that OO has over-subscribe the Allocation
> Slack and recommend QoS to handle the usage slack only. (MESOS-3889)
> {code}
> message Resource {
> ...
> message RevocableInfo {
>enum Type {
> // Under-utilized, allocated resources. Controlled by
> // oversubscription (QoSController & ResourceEstimator).
> USAGE_SLACK = 1;
> // Unallocated, reserved resources.
> // Controlled by optimistic offers (Allocator).
> ALLOCATION_SLACK = 2;
>}
>required Type type = 1;
> }
> ...
> optional RevocableInfo revocable = 9;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3888) Support distinguishing revocable resources in the Resource protobuf.
[
https://issues.apache.org/jira/browse/MESOS-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3888:
Description:
Add enum type into RevocableInfo:
* Framework need to assign RevocableInfo when launching task; if it’s not
assign, use reserved resources. Framework need to identify which resources it’s
using
* Oversubscription resources need to assign the type by Agent (MESOS-3930)
* Update Oversubscription document that OO has over-subscribe the Allocation
Slack and recommend QoS to handle the usage slack only. (MESOS-3889)
{code}
message Resource {
...
message RevocableInfo {
enum Type {
// Under-utilized, allocated resources. Controlled by
// oversubscription (QoSController & ResourceEstimator).
USAGE_SLACK = 1;
// Unallocated, reserved resources.
// Controlled by optimistic offers (Allocator).
ALLOCATION_SLACK = 2;
}
optional Type type = 1;
}
...
optional RevocableInfo revocable = 9;
}
{code}
was:
Add enum type into RevocableInfo:
* Framework need to assign RevocableInfo when launching task; if it’s not
assign, use reserved resources. Framework need to identify which resources it’s
using
* Oversubscription resources need to assign the type by Agent (MESOS-3930)
* Update Oversubscription document that OO has over-subscribe the Allocation
Slack and recommend QoS to handle the usage slack only. (MESOS-3889)
{code}
message Resource {
...
message RevocableInfo {
enum Type {
// Under-utilized, allocated resources. Controlled by
// oversubscription (QoSController & ResourceEstimator).
USAGE_SLACK = 1;
// Unallocated, reserved resources.
// Controlled by optimistic offers (Allocator).
ALLOCATION_SLACK = 2;
}
required Type type = 1;
}
...
optional RevocableInfo revocable = 9;
}
{code}
> Support distinguishing revocable resources in the Resource protobuf.
>
>
> Key: MESOS-3888
> URL: https://issues.apache.org/jira/browse/MESOS-3888
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Klaus Ma
> Labels: mesosphere
>
> Add enum type into RevocableInfo:
> * Framework need to assign RevocableInfo when launching task; if it’s not
> assign, use reserved resources. Framework need to identify which resources
> it’s using
> * Oversubscription resources need to assign the type by Agent (MESOS-3930)
> * Update Oversubscription document that OO has over-subscribe the Allocation
> Slack and recommend QoS to handle the usage slack only. (MESOS-3889)
> {code}
> message Resource {
> ...
> message RevocableInfo {
>enum Type {
> // Under-utilized, allocated resources. Controlled by
> // oversubscription (QoSController & ResourceEstimator).
> USAGE_SLACK = 1;
> // Unallocated, reserved resources.
> // Controlled by optimistic offers (Allocator).
> ALLOCATION_SLACK = 2;
>}
>optional Type type = 1;
> }
> ...
> optional RevocableInfo revocable = 9;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3891) Add a helper function to the Agent to check available resources before launching a task.
[
https://issues.apache.org/jira/browse/MESOS-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3891:
Description:
Launching a task using revocable resources should be funnelled through an
accounting system:
* If a task is launched using revocable resources, the resources must not be in
use when launching the task. If they are in use, then the task should fail to
start.
* If a task is launched using reserved resources, the resources must be made
available. This means potentially evicting tasks which are using revocable
resources.
Both cases could be implemented by adding a check in Slave::runTask, like a new
helper method:
{noformat}
class Slave {
...
// Checks if the given resources are available (i.e. not utilized)
// for starting a task. If not, the task should either fail to
// start or result in the eviction of revocable resources.
virtual process::Future checkAvailableResources(
const Resources& resources);
...
}
{noformat}
was:
{noformat}
class Slave {
...
// Checks if the given resources are available (i.e. not utilized)
// for starting a task. If not, the task should either fail to
// start or result in the eviction of revocable resources.
virtual process::Future checkAvailableResources(
const Resources& resources);
...
}
{noformat}
> Add a helper function to the Agent to check available resources before
> launching a task.
> -
>
> Key: MESOS-3891
> URL: https://issues.apache.org/jira/browse/MESOS-3891
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Artem Harutyunyan
> Labels: mesosphere
>
> Launching a task using revocable resources should be funnelled through an
> accounting system:
> * If a task is launched using revocable resources, the resources must not be
> in use when launching the task. If they are in use, then the task should
> fail to start.
> * If a task is launched using reserved resources, the resources must be made
> available. This means potentially evicting tasks which are using revocable
> resources.
> Both cases could be implemented by adding a check in Slave::runTask, like a
> new helper method:
> {noformat}
> class Slave {
> ...
> // Checks if the given resources are available (i.e. not utilized)
> // for starting a task. If not, the task should either fail to
> // start or result in the eviction of revocable resources.
> virtual process::Future checkAvailableResources(
> const Resources& resources);
> ...
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3955) Add helper function to get stateless resources.
[
https://issues.apache.org/jira/browse/MESOS-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3955:
Description:
Stateless are {{No Persistent Volume}} resources, it’s used by allocator to
calculate optimised resources (stateless - unreserved - reserved(role)).
{code}
class Resources {
...
// Tests if the given Resource object has no stateful elements.
static bool isStateless(const Resource& resource);
...
// Returns the resources that do not have stateful elements.
Resources stateless() const;
...
}
{code}
was:
{code}
class Resources {
...
// Tests if the given Resource object has no stateful elements.
static bool isStateless(const Resource& resource);
...
// Returns the resources that do not have stateful elements.
Resources stateless() const;
...
}
{code}
> Add helper function to get stateless resources.
> ---
>
> Key: MESOS-3955
> URL: https://issues.apache.org/jira/browse/MESOS-3955
> Project: Mesos
> Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Guangya Liu
>
> Stateless are {{No Persistent Volume}} resources, it’s used by allocator to
> calculate optimised resources (stateless - unreserved - reserved(role)).
> {code}
> class Resources {
> ...
> // Tests if the given Resource object has no stateful elements.
> static bool isStateless(const Resource& resource);
> ...
> // Returns the resources that do not have stateful elements.
> Resources stateless() const;
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3892) Add a helper function to the Agent to retrieve the list of executors that are using optimistically offered, revocable resources.
[
https://issues.apache.org/jira/browse/MESOS-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3892:
Description:
The Mesos master already keeps track of all executors running on a given agent.
We may wish to add a helper to retrieve the evictable executors:
* The evictable executor will hash by role; only Lender Framework/Role can
reclaim its resources back
* The RevocableInfo::type of executor & task must be consistent (MESOS-)
{noformat}
class Slave {
...
// How the master currently keeps track of executors.
hashmap> executors;
...
// Returns the list of executors that are using optimistically-
// offered, revocable resources.
list getEvictableExecutors() { ... }
...
}
{noformat}
was:
{noformat}
class Slave {
...
// How the master currently keeps track of executors.
hashmap> executors;
...
// Returns the list of executors that are using optimistically-
// offered, revocable resources.
list getEvictableExecutors() { ... }
...
}
{noformat}
> Add a helper function to the Agent to retrieve the list of executors that are
> using optimistically offered, revocable resources.
>
>
> Key: MESOS-3892
> URL: https://issues.apache.org/jira/browse/MESOS-3892
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Klaus Ma
> Labels: mesosphere
>
> The Mesos master already keeps track of all executors running on a given
> agent. We may wish to add a helper to retrieve the evictable executors:
> * The evictable executor will hash by role; only Lender Framework/Role can
> reclaim its resources back
> * The RevocableInfo::type of executor & task must be consistent (MESOS-)
> {noformat}
> class Slave {
> ...
> // How the master currently keeps track of executors.
> hashmap> executors;
> ...
> // Returns the list of executors that are using optimistically-
> // offered, revocable resources.
> list getEvictableExecutors() { ... }
> ...
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3892) Add a helper function to the Agent to retrieve the list of executors that are using optimistically offered, revocable resources.
[
https://issues.apache.org/jira/browse/MESOS-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-3892:
Description:
{noformat}
class Slave {
...
// How the master currently keeps track of executors.
hashmap> executors;
...
// Returns the list of executors that are using optimistically-
// offered, revocable resources.
list getEvictableExecutors() { ... }
...
}
{noformat}
was:
The Mesos master already keeps track of all executors running on a given agent.
We may wish to add a helper to retrieve the evictable executors:
* The evictable executor will hash by role; only Lender Framework/Role can
reclaim its resources back
* The RevocableInfo::type of executor & task must be consistent (MESOS-)
{noformat}
class Slave {
...
// How the master currently keeps track of executors.
hashmap> executors;
...
// Returns the list of executors that are using optimistically-
// offered, revocable resources.
list getEvictableExecutors() { ... }
...
}
{noformat}
> Add a helper function to the Agent to retrieve the list of executors that are
> using optimistically offered, revocable resources.
>
>
> Key: MESOS-3892
> URL: https://issues.apache.org/jira/browse/MESOS-3892
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Klaus Ma
> Labels: mesosphere
>
> {noformat}
> class Slave {
> ...
> // How the master currently keeps track of executors.
> hashmap> executors;
> ...
> // Returns the list of executors that are using optimistically-
> // offered, revocable resources.
> list getEvictableExecutors() { ... }
> ...
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
