[jira] [Commented] (MESOS-9159) Support Foreign URLs in docker registry puller on windows.
[ https://issues.apache.org/jira/browse/MESOS-9159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819583#comment-16819583 ] Gilbert Song commented on MESOS-9159: - Closed since windows support on external URLs is already done > Support Foreign URLs in docker registry puller on windows. > -- > > Key: MESOS-9159 > URL: https://issues.apache.org/jira/browse/MESOS-9159 > Project: Mesos > Issue Type: Task >Reporter: Akash Gupta >Assignee: Liangyu Zhao >Priority: Major > Fix For: 1.4.4, 1.5.4, 1.6.3, 1.7.3, 1.8.0 > > > Currently, trying to pull the layers of a Windows image with the current > registry pull code will return a 404 error. This is because the Windows > docker images need to pull the base OS layers from the foreign URLs field in > the version 2 schema 2 docker manifest. As a result, the register puller > needs to be aware of version 2 schema 2 and the foreign urls field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9723) Apply in place permutation to avoid copying when doing random shuffling.
[ https://issues.apache.org/jira/browse/MESOS-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819468#comment-16819468 ] Meng Zhu commented on MESOS-9723: - A prototype implementation here shows minimal performance improvement: https://reviews.apache.org/r/70469 Ran a modified sorter benchmark: Before: 10 runs of sort of 2000 clients took 9.113634ms After: 10 runs of sort of 2000 clients took 8.802126ms This does not seem to worth the extra complexity. > Apply in place permutation to avoid copying when doing random shuffling. > > > Key: MESOS-9723 > URL: https://issues.apache.org/jira/browse/MESOS-9723 > Project: Mesos > Issue Type: Improvement >Reporter: Meng Zhu >Assignee: Meng Zhu >Priority: Major > Labels: performance, resource-management > > This should improve the performance of random sorter. Se [~bmahler]'s comment > here: > https://github.com/apache/mesos/blob/master/src/master/allocator/sorter/random/utils.hpp#L69-L74 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-9710) Add tests to ensure random sorter performs correct weighted sorting.
[
https://issues.apache.org/jira/browse/MESOS-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819434#comment-16819434
]
Benjamin Mahler commented on MESOS-9710:
{noformat}
commit a03db7d684f343656aa229771f30c4990a2839c1
Author: Benjamin Mahler
Date: Tue Apr 9 17:08:02 2019 -0400
Added a test of hierarchical sorting for the random sorter.
Review: https://reviews.apache.org/r/70438
{noformat}
> Add tests to ensure random sorter performs correct weighted sorting.
>
>
> Key: MESOS-9710
> URL: https://issues.apache.org/jira/browse/MESOS-9710
> Project: Mesos
> Issue Type: Task
> Components: allocation
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>Priority: Major
>
> We added tests for the weighted shuffle algorithm, but didn't test that the
> RandomSorter's sort() function behaves correctly.
> We should also test that hierarchical weights in the random sorter behave
> correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8983) SlaveRecoveryTest/0.PingTimeoutDuringRecovery is flaky
[
https://issues.apache.org/jira/browse/MESOS-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819281#comment-16819281
]
Andrei Budnik commented on MESOS-8983:
--
This test fails pretty often on ARM.
> SlaveRecoveryTest/0.PingTimeoutDuringRecovery is flaky
> --
>
> Key: MESOS-8983
> URL: https://issues.apache.org/jira/browse/MESOS-8983
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.7.0, 1.8.0
>Reporter: Alexander Rojas
>Assignee: Joseph Wu
>Priority: Major
> Labels: flaky-test, foundations
>
> During an unrelated change in a PR, the apache build bot sent the following
> error:
> {noformat}
> @ 7FF71117D888
> std::invoke<,process::Future
> >,process::ProcessBase *>
> @ 7FF71119257B
> lambda::internal::Partial<,process::Future
> >,std::_Ph<1>
> >::invoke_expand<,std::tuple
> >,std::_Ph<1> >,st
> @ 7FF7110C08BA ) @ 7FF7110F058C
> std::_Invoker_functor::_Call,process::Future
> >,std::_Ph<1> >,process::ProcessBase *>
> @ 7FF711183EBC
> std::invoke,process::Future
> >,std::_Ph<1> >,process::ProcessBase *>
> @ 7FF7110C9F21
> ),process::Future
> >,std::_Ph<1> >,process::ProcessBase *
> @ 7FF711236416 process::ProcessBase
> *)>::CallableFn,process::Future
> >,std::_Ph<1> > >::operator(
> @ 7FF712C1A25D process::ProcessBase *)>::operator(
> @ 7FF712ACB2F9 process::ProcessBase::consume
> @ 7FF712C738CA process::DispatchEvent::consume
> @ 7FF70ECE7B07 process::ProcessBase::serve
> @ 7FF712AD93B0 process::ProcessManager::resume
> @ 7FF712C07371 ??
> @ 7FF712B2B130
> std::_Invoker_functor::_Call< >
> @ 7FF712B8B8E0
> std::invoke< >
> @ 7FF712B4076C
> std::_LaunchPad
> >,std::default_delete >
> > > >::_Execute<0>
> @ 7FF712C5A60A
> std::_LaunchPad
> >,std::default_delete >
> > > >::_Run
> @ 7FF712C45E78
> std::_LaunchPad
> >,std::default_delete >
> > > >::_Go
> @ 7FF712C2C3CD std::_Pad::_Call_func
> @ 7FFF9BE53428 _register_onexit_function
> @ 7FFF9BE53071 _register_onexit_function
> @ 7FFFB6391FE4 BaseThreadInitThunk
> @ 7FFFB69FF061 RtlUserThreadStart
> ll containerizers
> I0606 10:25:26.680230 18356 slave.cpp:7158] Recovering executors
> I0606 10:25:26.680230 18356 slave.cpp:7182] Sending reconnect request to
> executor '3f11d255-bb7b-4e99-967b-055fef95b595' of framework
> 62cf792a-dc69-4e3c-b54f-d83f98fb9451- at executor(1)@192.10.1.5:55652
> I0606 10:25:26.688225 22560 slave.cpp:4984] Received re-registration message
> from executor '3f11d255-bb7b-4e99-967b-055fef95b595' of framework
> 62cf792a-dc69-4e3c-b54f-d83f98fb9451-
> I0606 10:25:26.691216 22888 slave.cpp:5901] No pings from master received
> within 75secs
> F0606 10:25:26.692219 22888 slave.cpp:1249] Check failed: state ==
> DISCONNECTED || state == RUNNING || state == TERMINATING RECOVERING
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9732) Python installation using `make install` fails inside a symlinked directory
Benno Evers created MESOS-9732:
--
Summary: Python installation using `make install` fails inside a
symlinked directory
Key: MESOS-9732
URL: https://issues.apache.org/jira/browse/MESOS-9732
Project: Mesos
Issue Type: Bug
Reporter: Benno Evers
I used to have a symlink pointing from `~/mesos` to `~/src/mesos`.
Then I attempted to `make install` from inside the `~/mesos/worktrees/release`
directory on a build with python bindings enabled.
Now I don't have a symlink anymore.
{noformat}
bevers@poincare:~$ ls ~/src/mesos
3rdpartycompile install-sh mpi
aclocal.m4 config.guessLICENSE NOTICE
ar-lib config.sub ltmain.shREADME.md
autom4te.cache configure m4 site
bin configure.acMakefile.am src
bootstrap depcomp Makefile.in support
bootstrap.bat docsmesos.pc.in worktrees
CHANGELOG Doxyfilemesos.sublime-project
cmake etc_issue_orig mesos.sublime-workspace
CMakeLists.txt include missing
bevers@poincare:~$ ls ~/mesos
worktrees
bevers@poincare:~$ ls ~/mesos/worktrees/release/build/src/python/dist
mesos-1.8.0-py2.7.egg
mesos-1.8.0-py2-none-any.whl
mesos.cli-1.8.0-py2.7.egg
mesos.cli-1.8.0-py2-none-any.whl
mesos.executor-1.8.0-cp27-none-linux_x86_64.whl
mesos.executor-1.8.0-py2.7-linux-x86_64.egg
mesos.interface-1.8.0-py2.7.egg
mesos.interface-1.8.0-py2-none-any.whl
mesos.native-1.8.0-py2.7.egg
mesos.native-1.8.0-py2-none-any.whl
mesos.scheduler-1.8.0-cp27-none-linux_x86_64.whl
mesos.scheduler-1.8.0-py2.7-linux-x86_64.egg
{noformat}
The installation itself also fails with a predictable error:
{noformat}
OSError: [Errno 2] No such file or directory:
'/home/bevers/mesos/worktrees/release/build/../src/python/executor/src/mesos/executor'
{noformat}
Leaving the system in a funny state as a side effect:
{noformat}
bevers@poincare:~/mesos/worktrees/release/build$ ls .
3rdparty bin config.log config.lt config.status description-pak include
libtool Makefile mesos.pc mpi src
bevers@poincare:~/mesos/worktrees/release/build$ ls `pwd`
src
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9704) Support docker manifest v2s2 config GC.
[ https://issues.apache.org/jira/browse/MESOS-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song reassigned MESOS-9704: --- Shepherd: Qian Zhang Assignee: Gilbert Song Sprint: Containerization: RI-13 Sp 44 Story Points: 3 > Support docker manifest v2s2 config GC. > --- > > Key: MESOS-9704 > URL: https://issues.apache.org/jira/browse/MESOS-9704 > Project: Mesos > Issue Type: Improvement > Components: containerization >Reporter: Gilbert Song >Assignee: Gilbert Song >Priority: Major > Labels: containerization > > After docker manifest v2s2 support, layer GC is still properly supported. > However, the manifest config is not garbage collected. Need to add the config > dir to the checkpointed LAYERS_FILE to support config GC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
