[jira] [Updated] (MESOS-4470) Implement `uname` in Windows

[Michael Park (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Park updated MESOS-4470:

Description: (was: https://reviews.apache.org/r/46191/)

> Implement `uname` in Windows
> 
>
> Key: MESOS-4470
> URL: https://issues.apache.org/jira/browse/MESOS-4470
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere, stout, windows-mvp
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4470) Implement `uname` in Windows

[Michael Park (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253378#comment-15253378
 ] 

Michael Park commented on MESOS-4470:
-

https://reviews.apache.org/r/46191/

> Implement `uname` in Windows
> 
>
> Key: MESOS-4470
> URL: https://issues.apache.org/jira/browse/MESOS-4470
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere, stout, windows-mvp
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-4471) Implement process querying/counting in Windows

[Michael Park (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253371#comment-15253371
 ] 

Michael Park edited comment on MESOS-4471 at 4/22/16 5:33 AM:
--

{noformat}
commit 3fd64f4d7a569199e184733c6c448c91ad70733a
Author: Alex Clemmer 
Date:   Thu Apr 21 11:51:33 2016 -0700

Moved process tests to their own file to libprocess.

Review: https://reviews.apache.org/r/46015/
{noformat}
{noformat}
commit f79b8bbdc38ab7afafbf37eb63b87497650e12d9
Author: Alex Clemmer 
Date:   Thu Apr 21 11:51:28 2016 -0700

Moved process tests to their own file to stout.

Review: https://reviews.apache.org/r/46014/
{noformat}
{noformat}
commit d534d64def535179ff7db06570283184278c8a4c
Author: Alex Clemmer 
Date:   Thu Apr 21 11:51:25 2016 -0700

Implemented `os::processes` on Windows in stout.

Review: https://reviews.apache.org/r/46013/
{noformat}


was (Author: mcypark):
{noformat}
commit d534d64def535179ff7db06570283184278c8a4c
Author: Alex Clemmer 
Date:   Thu Apr 21 11:51:25 2016 -0700

Implemented `os::processes` on Windows in stout.

Review: https://reviews.apache.org/r/46013/
{noformat}

> Implement process querying/counting in Windows
> --
>
> Key: MESOS-4471
> URL: https://issues.apache.org/jira/browse/MESOS-4471
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere, stout, windows-mvp
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4471) Implement process querying/counting in Windows

[Michael Park (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253371#comment-15253371
 ] 

Michael Park commented on MESOS-4471:
-

{noformat}
commit d534d64def535179ff7db06570283184278c8a4c
Author: Alex Clemmer 
Date:   Thu Apr 21 11:51:25 2016 -0700

Implemented `os::processes` on Windows in stout.

Review: https://reviews.apache.org/r/46013/
{noformat}

> Implement process querying/counting in Windows
> --
>
> Key: MESOS-4471
> URL: https://issues.apache.org/jira/browse/MESOS-4471
> Project: Mesos
>  Issue Type: Bug
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere, stout, windows-mvp
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4988) Excluded reserved resources when got nonRevocable resources in stage 1.

[Klaus Ma (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253279#comment-15253279
 ] 

Klaus Ma commented on MESOS-4988:
-

RR: https://reviews.apache.org/r/45081/

> Excluded reserved resources when got nonRevocable resources in stage 1.
> ---
>
> Key: MESOS-4988
> URL: https://issues.apache.org/jira/browse/MESOS-4988
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>
> Allocator will only allocate non-revocable resources to satify quota. As the 
> reserved resources can not be revocable, it's not necessary to call 
> `nonRevocable()` for reserved resources.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5251) Enable "--explicitcreate" when call "dvdcli mount"

[Guangya Liu (JIRA)]

Guangya Liu created MESOS-5251:
--

 Summary: Enable "--explicitcreate" when call "dvdcli mount"
 Key: MESOS-5251
 URL: https://issues.apache.org/jira/browse/MESOS-5251
 Project: Mesos
  Issue Type: Bug
Reporter: Guangya Liu
Assignee: Guangya Liu


The dvdcli 0.1.0 will create volume by default if the volume does not exist 
when mounting, this is not a good behavior to create volumes blindly. Please 
refer to https://github.com/docker/docker/issues/21829 for some discussion with 
docker community.

The dvdcli has fixed this issue by introducing a new flag "--explicitcreate"  
to enable end user can customize the behavior of creating the volume by default 
or not. Please refer to https://github.com/emccode/dvdcli/issues/18 for some 
detail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-5244) Compilation failure on Ubuntu 16.04

[Chen Zhiwei (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chen Zhiwei reassigned MESOS-5244:
--

Assignee: Chen Zhiwei

> Compilation failure on Ubuntu 16.04
> ---
>
> Key: MESOS-5244
> URL: https://issues.apache.org/jira/browse/MESOS-5244
> Project: Mesos
>  Issue Type: Bug
>  Components: python api
>Reporter: Kapil Arya
>Assignee: Chen Zhiwei
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> I saw the following error when trying to compile Mesos on Ubuntu 16.04:
> {code}
> dekaksi:...mesos/build/src> make 
> ../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg
> Building protobuf Python egg ...
> cd ../3rdparty/protobuf-2.6.1/python && \
>   CC="gcc"  \
>   CXX="g++" \
>   CFLAGS="-g -O2 -Wno-unused-local-typedefs -g1 -O0"  
>   \
>   CXXFLAGS="-g -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> -std=c++11 -g1 -O0"   \
>   PYTHONPATH=/home/kapil/mesos/build/3rdparty/distribute-0.6.26 \
>   /usr/bin/python setup.py build bdist_egg
> Traceback (most recent call last):
>   File "setup.py", line 11, in 
> from setuptools import setup, Extension
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/__init__.py", 
> line 2, in 
> from setuptools.extension import Extension, Library
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/extension.py", 
> line 5, in 
> from setuptools.dist import _get_unpatched
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/dist.py", line 
> 6, in 
> from setuptools.command.install import install
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/__init__.py",
>  line 8, in 
> from setuptools.command import install_scripts
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/install_scripts.py",
>  line 3, in 
> from pkg_resources import Distribution, PathMetadata, ensure_directory
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2731, in 
> add_activation_listener(lambda dist: dist.activate())
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 704, in subscribe
> callback(dist)
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2731, in 
> add_activation_listener(lambda dist: dist.activate())
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2231, in activate
> self.insert_on(path)
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2332, in insert_on
> "with distribute. Found one at %s" % str(self.location))
> ValueError: A 0.7-series setuptools cannot be installed with distribute. 
> Found one at /usr/lib/python2.7/dist-packages
> Makefile:10869: recipe for target 
> '../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg' failed
> make: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg] 
> Error 1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3402) mesos-execute does not support credentials

[Vinod Kone (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone updated MESOS-3402:
--
Shepherd: Vinod Kone
  Sprint: Mesosphere Sprint 33
Story Points: 2

> mesos-execute does not support credentials
> --
>
> Key: MESOS-3402
> URL: https://issues.apache.org/jira/browse/MESOS-3402
> Project: Mesos
>  Issue Type: Bug
>Reporter: Evan Krall
>Assignee: Tim Anderegg
>
> mesos-execute does not appear to support passing credentials. This makes it 
> impossible to use on a cluster where framework authentication is required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253054#comment-15253054
 ] 

haosdent commented on MESOS-1104:
-

[~xds2000] I think the reason to keep it in current folder is those functions 
now only can be used in Linux, just like {{src/linux/ns.hpp}}. But if we want 
to support them in osx or windows in the future, I think move to stout would be 
better because it places the generic utilities.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252990#comment-15252990
 ] 

Deshi Xiao commented on MESOS-1104:
---

i think the file convention is follow the current folder. if move it to stout, 
also need consider what benefit on the action. Could you please list some 
concerns let me understand your think?

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5064) Remove default value for the agent `work_dir`

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-5064:
-
Shepherd: Michael Park  (was: Jie Yu)

> Remove default value for the agent `work_dir`
> -
>
> Key: MESOS-5064
> URL: https://issues.apache.org/jira/browse/MESOS-5064
> Project: Mesos
>  Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Greg Mann
>
> Following a crash report from the user we need to be more explicit about the 
> dangers of using {{/tmp}} as agent {{work_dir}}. In addition, we can remove 
> the default value for the {{\-\-work_dir}} flag, forcing users to explicitly 
> set the work directory for the agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-4434) Install 3rdparty package boost, glog, protobuf and picojson when installing Mesos

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya reassigned MESOS-4434:
-

Assignee: Kapil Arya

> Install 3rdparty package boost, glog, protobuf and picojson when installing 
> Mesos
> -
>
> Key: MESOS-4434
> URL: https://issues.apache.org/jira/browse/MESOS-4434
> Project: Mesos
>  Issue Type: Bug
>  Components: build, modules
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> Mesos modules depend on having these packages installed with the exact 
> version as Mesos was compiled with.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5250) Move 3rdparty/libprocess/3rdparty/* to 3rdparty/

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5250:
-

 Summary: Move 3rdparty/libprocess/3rdparty/* to 3rdparty/
 Key: MESOS-5250
 URL: https://issues.apache.org/jira/browse/MESOS-5250
 Project: Mesos
  Issue Type: Task
Reporter: Kapil Arya
Assignee: Kapil Arya






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (MESOS-5245) Sort entries in configure.ac and Makefile.am scripts

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya deleted MESOS-5245:
--


> Sort entries in configure.ac and Makefile.am scripts
> 
>
> Key: MESOS-5245
> URL: https://issues.apache.org/jira/browse/MESOS-5245
> Project: Mesos
>  Issue Type: Task
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (MESOS-5246) Add --with-stout flag to libprocess configure script

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya deleted MESOS-5246:
--


> Add --with-stout flag to libprocess configure script
> 
>
> Key: MESOS-5246
> URL: https://issues.apache.org/jira/browse/MESOS-5246
> Project: Mesos
>  Issue Type: Task
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (MESOS-5248) Move 3rdparty/libprocess/3rdparty/* to 3rdparty/

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya deleted MESOS-5248:
--


> Move 3rdparty/libprocess/3rdparty/* to 3rdparty/
> 
>
> Key: MESOS-5248
> URL: https://issues.apache.org/jira/browse/MESOS-5248
> Project: Mesos
>  Issue Type: Task
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (MESOS-5247) Add --with-libprocess and --with-stout to top-level configure.ac

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya deleted MESOS-5247:
--


> Add --with-libprocess and --with-stout to top-level configure.ac
> 
>
> Key: MESOS-5247
> URL: https://issues.apache.org/jira/browse/MESOS-5247
> Project: Mesos
>  Issue Type: Task
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> Also start using top-level configure script in lieu of libprocess/stout 
> configure scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5249) Update CMake files to reflect reorganized 3rdparty

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5249:
-

 Summary: Update CMake files to reflect reorganized 3rdparty
 Key: MESOS-5249
 URL: https://issues.apache.org/jira/browse/MESOS-5249
 Project: Mesos
  Issue Type: Task
  Components: build
Reporter: Kapil Arya
Assignee: Alex Clemmer
 Fix For: 0.29.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5246) Add --with-stout flag to libprocess configure script

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5246:
-

 Summary: Add --with-stout flag to libprocess configure script
 Key: MESOS-5246
 URL: https://issues.apache.org/jira/browse/MESOS-5246
 Project: Mesos
  Issue Type: Bug
  Components: build
Reporter: Kapil Arya
Assignee: Kapil Arya
 Fix For: 0.29.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5245) Sort entries in configure.ac and Makefile.am scripts

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-5245:
--
Issue Type: Task  (was: Bug)

> Sort entries in configure.ac and Makefile.am scripts
> 
>
> Key: MESOS-5245
> URL: https://issues.apache.org/jira/browse/MESOS-5245
> Project: Mesos
>  Issue Type: Task
>  Components: build
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5247) Add --with-libprocess and --with-stout to top-level configure.ac

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-5247:
--
Description: Also start using top-level configure script in lieu of 
libprocess/stout configure scripts.

> Add --with-libprocess and --with-stout to top-level configure.ac
> 
>
> Key: MESOS-5247
> URL: https://issues.apache.org/jira/browse/MESOS-5247
> Project: Mesos
>  Issue Type: Task
>  Components: build
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Also start using top-level configure script in lieu of libprocess/stout 
> configure scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5246) Add --with-stout flag to libprocess configure script

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-5246:
--
Story Points: 1  (was: 2)
  Issue Type: Task  (was: Bug)

> Add --with-stout flag to libprocess configure script
> 
>
> Key: MESOS-5246
> URL: https://issues.apache.org/jira/browse/MESOS-5246
> Project: Mesos
>  Issue Type: Task
>  Components: build
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5247) Add --with-libprocess and --with-stout to top-level configure.ac

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-5247:
--
Issue Type: Task  (was: Bug)
   Summary: Add --with-libprocess and --with-stout to top-level 
configure.ac  (was: Add --with-libprocess and --with-stout to top-level 
configure.ac.)

> Add --with-libprocess and --with-stout to top-level configure.ac
> 
>
> Key: MESOS-5247
> URL: https://issues.apache.org/jira/browse/MESOS-5247
> Project: Mesos
>  Issue Type: Task
>  Components: build
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
> Fix For: 0.29.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5248) Move 3rdparty/libprocess/3rdparty/* to 3rdparty/

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5248:
-

 Summary: Move 3rdparty/libprocess/3rdparty/* to 3rdparty/
 Key: MESOS-5248
 URL: https://issues.apache.org/jira/browse/MESOS-5248
 Project: Mesos
  Issue Type: Task
  Components: build
Reporter: Kapil Arya
Assignee: Kapil Arya
 Fix For: 0.29.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5247) Add --with-libprocess and --with-stout to top-level configure.ac.

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5247:
-

 Summary: Add --with-libprocess and --with-stout to top-level 
configure.ac.
 Key: MESOS-5247
 URL: https://issues.apache.org/jira/browse/MESOS-5247
 Project: Mesos
  Issue Type: Bug
  Components: build
Reporter: Kapil Arya
Assignee: Kapil Arya
 Fix For: 0.29.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4690) Reorganize 3rdparty directory

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-4690:
--
Issue Type: Epic  (was: Task)

> Reorganize 3rdparty directory
> -
>
> Key: MESOS-4690
> URL: https://issues.apache.org/jira/browse/MESOS-4690
> Project: Mesos
>  Issue Type: Epic
>  Components: build, libprocess, stout
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> This issues is currently being discussed in the dev mailing list:
> http://www.mail-archive.com/dev@mesos.apache.org/msg34349.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5245) Sort entries in configure.ac and Makefile.am scripts

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5245:
-

 Summary: Sort entries in configure.ac and Makefile.am scripts
 Key: MESOS-5245
 URL: https://issues.apache.org/jira/browse/MESOS-5245
 Project: Mesos
  Issue Type: Bug
  Components: build
Reporter: Kapil Arya
Assignee: Kapil Arya
 Fix For: 0.29.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5005) Enforce that DiskInfo principal is equal to framework/operator principal

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-5005:
-
Sprint: Mesosphere Sprint 32  (was: Mesosphere Sprint 32, Mesosphere Sprint 
33)

> Enforce that DiskInfo principal is equal to framework/operator principal
> 
>
> Key: MESOS-5005
> URL: https://issues.apache.org/jira/browse/MESOS-5005
> Project: Mesos
>  Issue Type: Bug
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: mesosphere, persistent-volumes, reservations
>
> Currently, we require that {{ReservationInfo.principal}} be equal to the 
> principal provided for authentication, which means that when HTTP 
> authentication is disabled this field cannot be set. Based on comments in 
> 'mesos.proto', the original intention was to enforce this same constraint for 
> {{Persistence.principal}}, but it seems that we don't enforce it. This should 
> be changed to make the two fields equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4690) Reorganize 3rdparty directory

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-4690:
--
  Sprint: Mesosphere Sprint 33
Story Points: 5

> Reorganize 3rdparty directory
> -
>
> Key: MESOS-4690
> URL: https://issues.apache.org/jira/browse/MESOS-4690
> Project: Mesos
>  Issue Type: Task
>  Components: build, libprocess, stout
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> This issues is currently being discussed in the dev mailing list:
> http://www.mail-archive.com/dev@mesos.apache.org/msg34349.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-4690) Reorganize 3rdparty directory

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya reassigned MESOS-4690:
-

Assignee: Kapil Arya

> Reorganize 3rdparty directory
> -
>
> Key: MESOS-4690
> URL: https://issues.apache.org/jira/browse/MESOS-4690
> Project: Mesos
>  Issue Type: Task
>  Components: build, libprocess, stout
>Reporter: Kapil Arya
>Assignee: Kapil Arya
>  Labels: mesosphere
>
> This issues is currently being discussed in the dev mailing list:
> http://www.mail-archive.com/dev@mesos.apache.org/msg34349.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4690) Reorganize 3rdparty directory

[Kapil Arya (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kapil Arya updated MESOS-4690:
--
Issue Type: Task  (was: Epic)

> Reorganize 3rdparty directory
> -
>
> Key: MESOS-4690
> URL: https://issues.apache.org/jira/browse/MESOS-4690
> Project: Mesos
>  Issue Type: Task
>  Components: build, libprocess, stout
>Reporter: Kapil Arya
>  Labels: mesosphere
>
> This issues is currently being discussed in the dev mailing list:
> http://www.mail-archive.com/dev@mesos.apache.org/msg34349.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5244) Compilation failure on Ubuntu 16.04

[Kapil Arya (JIRA)]

Kapil Arya created MESOS-5244:
-

 Summary: Compilation failure on Ubuntu 16.04
 Key: MESOS-5244
 URL: https://issues.apache.org/jira/browse/MESOS-5244
 Project: Mesos
  Issue Type: Bug
  Components: python api
Reporter: Kapil Arya
Priority: Blocker
 Fix For: 0.29.0


I saw the following error when trying to compile Mesos on Ubuntu 16.04:

{code}
dekaksi:...mesos/build/src> make 
../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg
Building protobuf Python egg ...
cd ../3rdparty/protobuf-2.6.1/python && \
  CC="gcc"  \
  CXX="g++" \
  CFLAGS="-g -O2 -Wno-unused-local-typedefs -g1 -O0"
\
  CXXFLAGS="-g -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
-std=c++11 -g1 -O0"   \
  PYTHONPATH=/home/kapil/mesos/build/3rdparty/distribute-0.6.26 \
  /usr/bin/python setup.py build bdist_egg
Traceback (most recent call last):
  File "setup.py", line 11, in 
from setuptools import setup, Extension
  File 
"/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/__init__.py", 
line 2, in 
from setuptools.extension import Extension, Library
  File 
"/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/extension.py", 
line 5, in 
from setuptools.dist import _get_unpatched
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/dist.py", 
line 6, in 
from setuptools.command.install import install
  File 
"/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/__init__.py",
 line 8, in 
from setuptools.command import install_scripts
  File 
"/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/install_scripts.py",
 line 3, in 
from pkg_resources import Distribution, PathMetadata, ensure_directory
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
line 2731, in 
add_activation_listener(lambda dist: dist.activate())
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
line 704, in subscribe
callback(dist)
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
line 2731, in 
add_activation_listener(lambda dist: dist.activate())
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
line 2231, in activate
self.insert_on(path)
  File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
line 2332, in insert_on
"with distribute. Found one at %s" % str(self.location))
ValueError: A 0.7-series setuptools cannot be installed with distribute. Found 
one at /usr/lib/python2.7/dist-packages
Makefile:10869: recipe for target 
'../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg' failed
make: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg] 
Error 1
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4902) Add authentication to libprocess endpoints

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252693#comment-15252693
 ] 

Greg Mann commented on MESOS-4902:
--

Included in the review chain for this ticket are a couple patches to make 
{{/profiler/start}} and {{/profiler/stop}} functional again: MESOS-3319

> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
>  Issue Type: Improvement
>  Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> Adding HTTP authentication to these endpoints is a bit more complicated 
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4902) Add authentication to libprocess endpoints

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252691#comment-15252691
 ] 

Greg Mann commented on MESOS-4902:
--

Created a ticket to remove {{/system/stats.json}}: MESOS-5243

> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
>  Issue Type: Improvement
>  Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> Adding HTTP authentication to these endpoints is a bit more complicated 
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5243) Remove '/system/stats.json' endpoint

[Greg Mann (JIRA)]

Greg Mann created MESOS-5243:


 Summary: Remove '/system/stats.json' endpoint
 Key: MESOS-5243
 URL: https://issues.apache.org/jira/browse/MESOS-5243
 Project: Mesos
  Issue Type: Task
  Components: libprocess
Affects Versions: 0.28.1
Reporter: Greg Mann


The {{/system/stats.json}} endpoint was deprecated by MESOS-2058. This endpoint 
can now be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4090) Create light-weight executor only and scheduler only mesos eggs

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252604#comment-15252604
 ] 

Vinod Kone commented on MESOS-4090:
---

commit c426859d39e0e29f342e372ace17a039f0dd6180
Author: haosdent huang 
Date:   Thu Apr 21 13:24:24 2016 -0700

Fixed broken mesos.native package installation.

Review: https://reviews.apache.org/r/46372/


> Create light-weight executor only and scheduler only mesos eggs
> ---
>
> Key: MESOS-4090
> URL: https://issues.apache.org/jira/browse/MESOS-4090
> Project: Mesos
>  Issue Type: Improvement
>  Components: build
>Reporter: Steve Niemitz
>Assignee: Steve Niemitz
> Fix For: 0.29.0
>
>
> Currently, when running tasks in docker containers, if the executor uses the 
> mesos.native python library, the execution environment inside the container 
> (OS, native libs, etc) must match the execution environment outside the 
> container fairly closely in order to load the mesos.so library.
> The solution here can be to introduce a much lighter weight python egg, 
> mesos.executor, which only includes code (and dependencies) needed to create 
> and run an MesosExecutorDriver.  Executors can then use this native library 
> instead of mesos.native.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-4902) Add authentication to libprocess endpoints

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-4902:
-
Description: 
In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
following endpoints would also benefit from HTTP authentication:
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}

Adding HTTP authentication to these endpoints is a bit more complicated because 
they are defined at the libprocess level.

While working on MESOS-4850, it became apparent that since our tests use the 
same instance of libprocess for both master and agent, different default 
authentication realms must be used for master/agent so that HTTP authentication 
can be independently enabled/disabled for each.

We should establish a mechanism for making an endpoint authenticated that 
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and 
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit 
the use of different authentication realms for the master and agent and to keep 
application-level concerns from leaking into libprocess

Another option would be to use a single default authentication realm and always 
enable or disable HTTP authentication for *both* the master and agent in tests. 
However, this wouldn't allow us to test scenarios where HTTP authentication is 
enabled on one but disabled on the other.

  was:
In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
following endpoints would also benefit from HTTP authentication:
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/system/stats.json}}

Adding HTTP authentication to these endpoints is a bit more complicated because 
they are defined at the libprocess level.

While working on MESOS-4850, it became apparent that since our tests use the 
same instance of libprocess for both master and agent, different default 
authentication realms must be used for master/agent so that HTTP authentication 
can be independently enabled/disabled for each.

We should establish a mechanism for making an endpoint authenticated that 
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and 
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit 
the use of different authentication realms for the master and agent and to keep 
application-level concerns from leaking into libprocess

Another option would be to use a single default authentication realm and always 
enable or disable HTTP authentication for *both* the master and agent in tests. 
However, this wouldn't allow us to test scenarios where HTTP authentication is 
enabled on one but disabled on the other.


> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
>  Issue Type: Improvement
>  Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> Adding HTTP authentication to these endpoints is a bit more complicated 
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3319) Mesos will not build when configured with gperftools enabled

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-3319:
-
Shepherd: Kapil Arya

> Mesos will not build when configured with gperftools enabled
> 
>
> Key: MESOS-3319
> URL: https://issues.apache.org/jira/browse/MESOS-3319
> Project: Mesos
>  Issue Type: Bug
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: build
>
> Mesos configured with {{--enable-perftools}} currently will not build on OSX 
> 10.10.4 or Ubuntu 14.04, possibly because the bundled gperftools-2.0 is not 
> current. The stable release is now 2.4, which builds successfully on both of 
> these platforms.
> This issue is resolved when Mesos will build successfully out of the box with 
> gperftools enabled. After this ticket is resolved, the libprocess profiler 
> should be tested to confirm that it still works and if not, it should be 
> fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-3319) Mesos will not build when configured with gperftools enabled

[Greg Mann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Mann updated MESOS-3319:
-
  Sprint: Mesosphere Sprint 33
Story Points: 2

> Mesos will not build when configured with gperftools enabled
> 
>
> Key: MESOS-3319
> URL: https://issues.apache.org/jira/browse/MESOS-3319
> Project: Mesos
>  Issue Type: Bug
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: build
>
> Mesos configured with {{--enable-perftools}} currently will not build on OSX 
> 10.10.4 or Ubuntu 14.04, possibly because the bundled gperftools-2.0 is not 
> current. The stable release is now 2.4, which builds successfully on both of 
> these platforms.
> This issue is resolved when Mesos will build successfully out of the box with 
> gperftools enabled. After this ticket is resolved, the libprocess profiler 
> should be tested to confirm that it still works and if not, it should be 
> fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-3319) Mesos will not build when configured with gperftools enabled

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252440#comment-15252440
 ] 

Greg Mann commented on MESOS-3319:
--

This came up in the course of working on MESOS-4902, so we're going to address 
this at the same time. Bumping the gperftools version up to 2.5 fixes the build.

Reviews here:
https://reviews.apache.org/r/46461/
https://reviews.apache.org/r/46462/

> Mesos will not build when configured with gperftools enabled
> 
>
> Key: MESOS-3319
> URL: https://issues.apache.org/jira/browse/MESOS-3319
> Project: Mesos
>  Issue Type: Bug
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: build
>
> Mesos configured with {{--enable-perftools}} currently will not build on OSX 
> 10.10.4 or Ubuntu 14.04, possibly because the bundled gperftools-2.0 is not 
> current. The stable release is now 2.4, which builds successfully on both of 
> these platforms.
> This issue is resolved when Mesos will build successfully out of the box with 
> gperftools enabled. After this ticket is resolved, the libprocess profiler 
> should be tested to confirm that it still works and if not, it should be 
> fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5241) Porting Mesos to System z (s390x)

[Bing Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252390#comment-15252390
 ] 

Bing Li commented on MESOS-5241:


I'm sending a email to d...@mesos.apache.org .
Thanks,

> Porting Mesos to System z (s390x)
> -
>
> Key: MESOS-5241
> URL: https://issues.apache.org/jira/browse/MESOS-5241
> Project: Mesos
>  Issue Type: Epic
>Reporter: Bing Li
>
> The goal of this ticket is to make IBM System z (s390x) as a supported 
> architecture.
> The latest Mesos release version or master branch didn't built successfully 
> on s390x.
> We'll contribute our patches to make Mesos work on s390x .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5242) pivot_root is not available on System z (s390x)

[Bing Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252389#comment-15252389
 ] 

Bing Li commented on MESOS-5242:


Hi,

I have the patch already. It seems I'll need a reviewer, so that I can public 
my patch in Review Board.

Thanks,

> pivot_root is not available on System z (s390x)
> ---
>
> Key: MESOS-5242
> URL: https://issues.apache.org/jira/browse/MESOS-5242
> Project: Mesos
>  Issue Type: Bug
> Environment: Hardward: IBM System z
> OS: Linux on z SLES12SP1
>Reporter: Bing Li
>
> Got error "pivot_root is not available" which is similar to MESOS-5121 .
> Added syscall pivot_root definition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5242) pivot_root is not available on System z (s390x)

[Bing Li (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bing Li updated MESOS-5242:
---
Description: 
Got error "pivot_root is not available" which is similar to MESOS-5121 .
Added syscall pivot_root definition.




  was:
It is similar as MESOS-5121 .
Added syscall pivot_root definition.





> pivot_root is not available on System z (s390x)
> ---
>
> Key: MESOS-5242
> URL: https://issues.apache.org/jira/browse/MESOS-5242
> Project: Mesos
>  Issue Type: Bug
> Environment: Hardward: IBM System z
> OS: Linux on z SLES12SP1
>Reporter: Bing Li
>
> Got error "pivot_root is not available" which is similar to MESOS-5121 .
> Added syscall pivot_root definition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5241) Porting Mesos to System z (s390x)

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252358#comment-15252358
 ] 

haosdent commented on MESOS-5241:
-

Hi, you need send a email to {{d...@mesos.apache.org}} to ask a committer add 
you as contributor in jira first.

> Porting Mesos to System z (s390x)
> -
>
> Key: MESOS-5241
> URL: https://issues.apache.org/jira/browse/MESOS-5241
> Project: Mesos
>  Issue Type: Epic
>Reporter: Bing Li
>
> The goal of this ticket is to make IBM System z (s390x) as a supported 
> architecture.
> The latest Mesos release version or master branch didn't built successfully 
> on s390x.
> We'll contribute our patches to make Mesos work on s390x .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5241) Porting Mesos to System z (s390x)

[Bing Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252353#comment-15252353
 ] 

Bing Li commented on MESOS-5241:


Hi there,

I'm enabling Mesos on System z.

Maybe assign this Epic to me?
I'll open related issues under it.

Thanks,

> Porting Mesos to System z (s390x)
> -
>
> Key: MESOS-5241
> URL: https://issues.apache.org/jira/browse/MESOS-5241
> Project: Mesos
>  Issue Type: Epic
>Reporter: Bing Li
>
> The goal of this ticket is to make IBM System z (s390x) as a supported 
> architecture.
> The latest Mesos release version or master branch didn't built successfully 
> on s390x.
> We'll contribute our patches to make Mesos work on s390x .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[haosdent (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252351#comment-15252351
 ] 

haosdent commented on MESOS-1104:
-

Thank you very much for your patch, it looks to me basically besides I am not 
sure whether keep it in current folder or move it to {{stout}}.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5241) Porting Mesos to System z (s390x)

[Bing Li (JIRA)]

Bing Li created MESOS-5241:
--

 Summary: Porting Mesos to System z (s390x)
 Key: MESOS-5241
 URL: https://issues.apache.org/jira/browse/MESOS-5241
 Project: Mesos
  Issue Type: Epic
Reporter: Bing Li


The goal of this ticket is to make IBM System z (s390x) as a supported 
architecture.

The latest Mesos release version or master branch didn't built successfully on 
s390x.

We'll contribute our patches to make Mesos work on s390x .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5193) Recovery failed: Failed to recover registrar on reboot of mesos master

[Priyanka Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252298#comment-15252298
 ] 

Priyanka Gupta commented on MESOS-5193:
---

Thats right!

> Recovery failed: Failed to recover registrar on reboot of mesos master
> --
>
> Key: MESOS-5193
> URL: https://issues.apache.org/jira/browse/MESOS-5193
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.22.0, 0.27.0
>Reporter: Priyanka Gupta
>  Labels: master, mesosphere
> Attachments: node1.log, node2.log, node3.log
>
>
> Hi all, 
> We are using a 3 node cluster with mesos master, mesos slave and zookeeper on 
> all of them. We are using chronos on top of it. The problem is when we reboot 
> the mesos master leader, the other nodes try to get elected as leader but 
> fail with recovery registrar issue. 
> "Recovery failed: Failed to recover registrar: Failed to perform fetch within 
> 1mins"
> The next node then try to become the leader but again fails with same error. 
> I am not sure about the issue. We are currently using mesos 0.22 and also 
> tried to upgrade to mesos 0.27 as well but the problem continues to happen. 
>  /usr/sbin/mesos-master --work_dir=/tmp/mesos_dir 
> --zk=zk://node1:2181,node2:2181,node3:2181/mesos --quorum=2
> Can you please help us resolve this issue as its a production system.
> Thanks,
> Priyanka



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252296#comment-15252296
 ] 

Deshi Xiao commented on MESOS-1104:
---

[~haosdent]  [~mcypark]  could you please reive it 
again.https://reviews.apache.org/r/45500/

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5193) Recovery failed: Failed to recover registrar on reboot of mesos master

[Neil Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252293#comment-15252293
 ] 

Neil Conway commented on MESOS-5193:


Ah -- to clarify, *rebooting* the current leading master node causes the error 
to occur reliably. However, killing and restarting the {{mesos-master}} process 
on the current leading master node doesn't cause any problems. Is that accurate?

> Recovery failed: Failed to recover registrar on reboot of mesos master
> --
>
> Key: MESOS-5193
> URL: https://issues.apache.org/jira/browse/MESOS-5193
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.22.0, 0.27.0
>Reporter: Priyanka Gupta
>  Labels: master, mesosphere
> Attachments: node1.log, node2.log, node3.log
>
>
> Hi all, 
> We are using a 3 node cluster with mesos master, mesos slave and zookeeper on 
> all of them. We are using chronos on top of it. The problem is when we reboot 
> the mesos master leader, the other nodes try to get elected as leader but 
> fail with recovery registrar issue. 
> "Recovery failed: Failed to recover registrar: Failed to perform fetch within 
> 1mins"
> The next node then try to become the leader but again fails with same error. 
> I am not sure about the issue. We are currently using mesos 0.22 and also 
> tried to upgrade to mesos 0.27 as well but the problem continues to happen. 
>  /usr/sbin/mesos-master --work_dir=/tmp/mesos_dir 
> --zk=zk://node1:2181,node2:2181,node3:2181/mesos --quorum=2
> Can you please help us resolve this issue as its a production system.
> Thanks,
> Priyanka



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Deshi Xiao reassigned MESOS-1104:
-

Assignee: Deshi Xiao

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5193) Recovery failed: Failed to recover registrar on reboot of mesos master

[Priyanka Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252284#comment-15252284
 ] 

Priyanka Gupta commented on MESOS-5193:
---

[~neilc]: Its not a one time thing and its reproducible almost always. It 
happens only when I reboot the system. Shutting down mesos_master service works 
just fine. Not sure if its something to do with network going down. Its 
happening in production and hence kind of blocker for us.

Thanks,
Priyanka

> Recovery failed: Failed to recover registrar on reboot of mesos master
> --
>
> Key: MESOS-5193
> URL: https://issues.apache.org/jira/browse/MESOS-5193
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.22.0, 0.27.0
>Reporter: Priyanka Gupta
>  Labels: master, mesosphere
> Attachments: node1.log, node2.log, node3.log
>
>
> Hi all, 
> We are using a 3 node cluster with mesos master, mesos slave and zookeeper on 
> all of them. We are using chronos on top of it. The problem is when we reboot 
> the mesos master leader, the other nodes try to get elected as leader but 
> fail with recovery registrar issue. 
> "Recovery failed: Failed to recover registrar: Failed to perform fetch within 
> 1mins"
> The next node then try to become the leader but again fails with same error. 
> I am not sure about the issue. We are currently using mesos 0.22 and also 
> tried to upgrade to mesos 0.27 as well but the problem continues to happen. 
>  /usr/sbin/mesos-master --work_dir=/tmp/mesos_dir 
> --zk=zk://node1:2181,node2:2181,node3:2181/mesos --quorum=2
> Can you please help us resolve this issue as its a production system.
> Thanks,
> Priyanka



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5193) Recovery failed: Failed to recover registrar on reboot of mesos master

[Neil Conway (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252276#comment-15252276
 ] 

Neil Conway commented on MESOS-5193:


[~prigupta]: I dug into the logs. A few things seemed suspicious, but no 
smoking gun yet. A few questions to clarify:

1. Does this problem occur reliably, or was it a one-time issue?
2. If it is reproducible, can you start {{mesos-master}} with the {{GLOG_v=1}} 
set as an environmental variable? If this would cause production downtime, no 
need to bother.

> Recovery failed: Failed to recover registrar on reboot of mesos master
> --
>
> Key: MESOS-5193
> URL: https://issues.apache.org/jira/browse/MESOS-5193
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.22.0, 0.27.0
>Reporter: Priyanka Gupta
>  Labels: master, mesosphere
> Attachments: node1.log, node2.log, node3.log
>
>
> Hi all, 
> We are using a 3 node cluster with mesos master, mesos slave and zookeeper on 
> all of them. We are using chronos on top of it. The problem is when we reboot 
> the mesos master leader, the other nodes try to get elected as leader but 
> fail with recovery registrar issue. 
> "Recovery failed: Failed to recover registrar: Failed to perform fetch within 
> 1mins"
> The next node then try to become the leader but again fails with same error. 
> I am not sure about the issue. We are currently using mesos 0.22 and also 
> tried to upgrade to mesos 0.27 as well but the problem continues to happen. 
>  /usr/sbin/mesos-master --work_dir=/tmp/mesos_dir 
> --zk=zk://node1:2181,node2:2181,node3:2181/mesos --quorum=2
> Can you please help us resolve this issue as its a production system.
> Thanks,
> Priyanka



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4778) Add appc/runtime isolator for runtime isolation for appc images.

[Gilbert Song (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252209#comment-15252209
 ] 

Gilbert Song commented on MESOS-4778:
-

[~srbrahma]Thanks for the patches. I will start reviewing them.

> Add appc/runtime isolator for runtime isolation for appc images.
> 
>
> Key: MESOS-4778
> URL: https://issues.apache.org/jira/browse/MESOS-4778
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Srinivas
>
> Appc image also contains runtime information like 'exec', 'env', 
> 'workingDirectory' etc.
> https://github.com/appc/spec/blob/master/spec/aci.md
> Similar to docker images, we need to support a subset of them (mainly 'exec', 
> 'env' and 'workingDirectory').



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4778) Add appc/runtime isolator for runtime isolation for appc images.

[Srinivas (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252197#comment-15252197
 ] 

Srinivas commented on MESOS-4778:
-

3. Isolator is added. https://reviews.apache.org/r/46498/

[~gilbert] [~jieyu] can you please shepherd and review these patches.

> Add appc/runtime isolator for runtime isolation for appc images.
> 
>
> Key: MESOS-4778
> URL: https://issues.apache.org/jira/browse/MESOS-4778
> Project: Mesos
>  Issue Type: Task
>Reporter: Jie Yu
>Assignee: Srinivas
>
> Appc image also contains runtime information like 'exec', 'env', 
> 'workingDirectory' etc.
> https://github.com/appc/spec/blob/master/spec/aci.md
> Similar to docker images, we need to support a subset of them (mainly 'exec', 
> 'env' and 'workingDirectory').



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-4902) Add authentication to libprocess endpoints

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242554#comment-15242554
 ] 

Greg Mann edited comment on MESOS-4902 at 4/21/16 4:26 PM:
---

Reviews here:
https://reviews.apache.org/r/46258/
https://reviews.apache.org/r/46259/
https://reviews.apache.org/r/46260/
https://reviews.apache.org/r/46261/
https://reviews.apache.org/r/46262/
https://reviews.apache.org/r/46497/

The above reviews take care of all listed endpoints except for 
{{/system/stats.json}}, which has been deprecated (MESOS-2058).


was (Author: greggomann):
Reviews here:
https://reviews.apache.org/r/46258/
https://reviews.apache.org/r/46259/
https://reviews.apache.org/r/46260/
https://reviews.apache.org/r/46261/
https://reviews.apache.org/r/46262/

The above reviews take care of the {{/logging/toggle}} and 
{{/metrics/snapshot}} endpoints. I'll wait to move this ticket to "Reviewable" 
until the rest of the patches are up.

> Add authentication to libprocess endpoints
> --
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
>  Issue Type: Improvement
>  Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
>  Labels: authentication, http, mesosphere, security
> Fix For: 0.29.0
>
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-5152, the 
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> * {{/system/stats.json}}
> Adding HTTP authentication to these endpoints is a bit more complicated 
> because they are defined at the libprocess level.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-4279) Graceful restart of docker task

[Alexander Rukletsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252057#comment-15252057
 ] 

Alexander Rukletsov commented on MESOS-4279:


We should definitely separate them! Thanks for moving them to the reviewboard.

> Graceful restart of docker task
> ---
>
> Key: MESOS-4279
> URL: https://issues.apache.org/jira/browse/MESOS-4279
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.2
>Reporter: Martin Bydzovsky
>Assignee: Qian Zhang
>  Labels: docker, mesosphere
>
> I'm implementing a graceful restarts of our mesos-marathon-docker setup and I 
> came to a following issue:
> (it was already discussed on 
> https://github.com/mesosphere/marathon/issues/2876 and guys form mesosphere 
> got to a point that its probably a docker containerizer problem...)
> To sum it up:
> When i deploy simple python script to all mesos-slaves:
> {code}
> #!/usr/bin/python
> from time import sleep
> import signal
> import sys
> import datetime
> def sigterm_handler(_signo, _stack_frame):
> print "got %i" % _signo
> print datetime.datetime.now().time()
> sys.stdout.flush()
> sleep(2)
> print datetime.datetime.now().time()
> print "ending"
> sys.stdout.flush()
> sys.exit(0)
> signal.signal(signal.SIGTERM, sigterm_handler)
> signal.signal(signal.SIGINT, sigterm_handler)
> try:
> print "Hello"
> i = 0
> while True:
> i += 1
> print datetime.datetime.now().time()
> print "Iteration #%i" % i
> sys.stdout.flush()
> sleep(1)
> finally:
> print "Goodbye"
> {code}
> and I run it through Marathon like
> {code:javascript}
> data = {
>   args: ["/tmp/script.py"],
>   instances: 1,
>   cpus: 0.1,
>   mem: 256,
>   id: "marathon-test-api"
> }
> {code}
> During the app restart I get expected result - the task receives sigterm and 
> dies peacefully (during my script-specified 2 seconds period)
> But when i wrap this python script in a docker:
> {code}
> FROM node:4.2
> RUN mkdir /app
> ADD . /app
> WORKDIR /app
> ENTRYPOINT []
> {code}
> and run appropriate application by Marathon:
> {code:javascript}
> data = {
>   args: ["./script.py"],
>   container: {
>   type: "DOCKER",
>   docker: {
>   image: "bydga/marathon-test-api"
>   },
>   forcePullImage: yes
>   },
>   cpus: 0.1,
>   mem: 256,
>   instances: 1,
>   id: "marathon-test-api"
> }
> {code}
> The task during restart (issued from marathon) dies immediately without 
> having a chance to do any cleanup.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-5240) Command executor may escalate after the task is reaped.

[Alexander Rukletsov (JIRA)]

Alexander Rukletsov created MESOS-5240:
--

 Summary: Command executor may escalate after the task is reaped.
 Key: MESOS-5240
 URL: https://issues.apache.org/jira/browse/MESOS-5240
 Project: Mesos
  Issue Type: Bug
Affects Versions: 0.28.1, 0.26.1, 0.27.2
Reporter: Alexander Rukletsov
Assignee: Alexander Rukletsov
Priority: Minor
 Fix For: 0.29.0


In command executor, {{escalated()}} may be scheduled before the task has been 
killed, i.e. {{reaped()}}, but called after. In this case {{escalated()}} 
should be a no-op.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-5146) MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky.

[Alexander Rukletsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-5146:
---
Shepherd: Alexander Rukletsov
  Sprint: Mesosphere Sprint 33
Story Points: 1

> MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky.
> ---
>
> Key: MESOS-5146
> URL: https://issues.apache.org/jira/browse/MESOS-5146
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation, tests
>Affects Versions: 0.28.0
> Environment: Ubuntu 14.04 using clang, without libevent or SSL
>Reporter: Greg Mann
>Assignee: Yongqiao Wang
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Observed on the ASF CI:
> {code}
> [ RUN  ] MasterAllocatorTest/1.RebalancedForUpdatedWeights
> I0407 22:34:10.330394 29278 cluster.cpp:149] Creating default 'local' 
> authorizer
> I0407 22:34:10.466182 29278 leveldb.cpp:174] Opened db in 135.608207ms
> I0407 22:34:10.516398 29278 leveldb.cpp:181] Compacted db in 50.159558ms
> I0407 22:34:10.516464 29278 leveldb.cpp:196] Created db iterator in 34959ns
> I0407 22:34:10.516484 29278 leveldb.cpp:202] Seeked to beginning of db in 
> 10195ns
> I0407 22:34:10.516496 29278 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 7324ns
> I0407 22:34:10.516547 29278 replica.cpp:779] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0407 22:34:10.517277 29298 recover.cpp:447] Starting replica recovery
> I0407 22:34:10.517693 29300 recover.cpp:473] Replica is in EMPTY status
> I0407 22:34:10.520251 29310 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from (4775)@172.17.0.3:35855
> I0407 22:34:10.520611 29311 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I0407 22:34:10.521164 29299 recover.cpp:564] Updating replica status to 
> STARTING
> I0407 22:34:10.523435 29298 master.cpp:382] Master 
> f59f9057-a5c7-43e1-b129-96862e640a12 (129e11060069) started on 
> 172.17.0.3:35855
> I0407 22:34:10.523473 29298 master.cpp:384] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/3rZY8C/credentials" --framework_sorter="drf" 
> --help="false" --hostname_lookup="true" --http_authenticators="basic" 
> --initialize_driver_logging="true" --log_auto_initialize="true" 
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50" 
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5" 
> --quiet="false" --recovery_slave_removal_limit="100%" 
> --registry="replicated_log" --registry_fetch_timeout="1mins" 
> --registry_store_timeout="100secs" --registry_strict="true" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.29.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/3rZY8C/master" --zk_session_timeout="10secs"
> I0407 22:34:10.523885 29298 master.cpp:433] Master only allowing 
> authenticated frameworks to register
> I0407 22:34:10.523901 29298 master.cpp:438] Master only allowing 
> authenticated agents to register
> I0407 22:34:10.523913 29298 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/3rZY8C/credentials'
> I0407 22:34:10.524298 29298 master.cpp:480] Using default 'crammd5' 
> authenticator
> I0407 22:34:10.524441 29298 master.cpp:551] Using default 'basic' HTTP 
> authenticator
> I0407 22:34:10.524564 29298 master.cpp:589] Authorization enabled
> I0407 22:34:10.525269 29305 hierarchical.cpp:145] Initialized hierarchical 
> allocator process
> I0407 22:34:10.525333 29305 whitelist_watcher.cpp:77] No whitelist given
> I0407 22:34:10.527331 29298 master.cpp:1832] The newly elected leader is 
> master@172.17.0.3:35855 with id f59f9057-a5c7-43e1-b129-96862e640a12
> I0407 22:34:10.527441 29298 master.cpp:1845] Elected as the leading master!
> I0407 22:34:10.527545 29298 master.cpp:1532] Recovering from registrar
> I0407 22:34:10.527889 29298 registrar.cpp:331] Recovering registrar
> I0407 22:34:10.549734 29299 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 28.25177ms
> I0407 22:34:10.549782 29299 replica.cpp:320] Persisted replica status to 
> STARTING
> I0407 22:34:10.550010 29299 recover.cpp:473] Replica is in STARTING status
> I0407 22:34:10.551352 29299 replica.cpp:673] Replica in STARTING status 
> received a broadcasted recover request from (4777)@172.17.0.3:35855
> I0407 22:34:10.551676 29299 recover.cpp:193] Received a recover response from 
> a replica in STARTING status
> I0407 22:34:10.552315 29308 recover.cpp:564] Updating 

[jira] [Updated] (MESOS-5146) MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky.

[Alexander Rukletsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Rukletsov updated MESOS-5146:
---
Summary: MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky.  (was: 
MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky)

> MasterAllocatorTest/1.RebalancedForUpdatedWeights is flaky.
> ---
>
> Key: MESOS-5146
> URL: https://issues.apache.org/jira/browse/MESOS-5146
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation, tests
>Affects Versions: 0.28.0
> Environment: Ubuntu 14.04 using clang, without libevent or SSL
>Reporter: Greg Mann
>Assignee: Yongqiao Wang
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Observed on the ASF CI:
> {code}
> [ RUN  ] MasterAllocatorTest/1.RebalancedForUpdatedWeights
> I0407 22:34:10.330394 29278 cluster.cpp:149] Creating default 'local' 
> authorizer
> I0407 22:34:10.466182 29278 leveldb.cpp:174] Opened db in 135.608207ms
> I0407 22:34:10.516398 29278 leveldb.cpp:181] Compacted db in 50.159558ms
> I0407 22:34:10.516464 29278 leveldb.cpp:196] Created db iterator in 34959ns
> I0407 22:34:10.516484 29278 leveldb.cpp:202] Seeked to beginning of db in 
> 10195ns
> I0407 22:34:10.516496 29278 leveldb.cpp:271] Iterated through 0 keys in the 
> db in 7324ns
> I0407 22:34:10.516547 29278 replica.cpp:779] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0407 22:34:10.517277 29298 recover.cpp:447] Starting replica recovery
> I0407 22:34:10.517693 29300 recover.cpp:473] Replica is in EMPTY status
> I0407 22:34:10.520251 29310 replica.cpp:673] Replica in EMPTY status received 
> a broadcasted recover request from (4775)@172.17.0.3:35855
> I0407 22:34:10.520611 29311 recover.cpp:193] Received a recover response from 
> a replica in EMPTY status
> I0407 22:34:10.521164 29299 recover.cpp:564] Updating replica status to 
> STARTING
> I0407 22:34:10.523435 29298 master.cpp:382] Master 
> f59f9057-a5c7-43e1-b129-96862e640a12 (129e11060069) started on 
> 172.17.0.3:35855
> I0407 22:34:10.523473 29298 master.cpp:384] Flags at startup: --acls="" 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true" 
> --authenticators="crammd5" --authorizers="local" 
> --credentials="/tmp/3rZY8C/credentials" --framework_sorter="drf" 
> --help="false" --hostname_lookup="true" --http_authenticators="basic" 
> --initialize_driver_logging="true" --log_auto_initialize="true" 
> --logbufsecs="0" --logging_level="INFO" --max_completed_frameworks="50" 
> --max_completed_tasks_per_framework="1000" --max_slave_ping_timeouts="5" 
> --quiet="false" --recovery_slave_removal_limit="100%" 
> --registry="replicated_log" --registry_fetch_timeout="1mins" 
> --registry_store_timeout="100secs" --registry_strict="true" 
> --root_submissions="true" --slave_ping_timeout="15secs" 
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false" 
> --webui_dir="/mesos/mesos-0.29.0/_inst/share/mesos/webui" 
> --work_dir="/tmp/3rZY8C/master" --zk_session_timeout="10secs"
> I0407 22:34:10.523885 29298 master.cpp:433] Master only allowing 
> authenticated frameworks to register
> I0407 22:34:10.523901 29298 master.cpp:438] Master only allowing 
> authenticated agents to register
> I0407 22:34:10.523913 29298 credentials.hpp:37] Loading credentials for 
> authentication from '/tmp/3rZY8C/credentials'
> I0407 22:34:10.524298 29298 master.cpp:480] Using default 'crammd5' 
> authenticator
> I0407 22:34:10.524441 29298 master.cpp:551] Using default 'basic' HTTP 
> authenticator
> I0407 22:34:10.524564 29298 master.cpp:589] Authorization enabled
> I0407 22:34:10.525269 29305 hierarchical.cpp:145] Initialized hierarchical 
> allocator process
> I0407 22:34:10.525333 29305 whitelist_watcher.cpp:77] No whitelist given
> I0407 22:34:10.527331 29298 master.cpp:1832] The newly elected leader is 
> master@172.17.0.3:35855 with id f59f9057-a5c7-43e1-b129-96862e640a12
> I0407 22:34:10.527441 29298 master.cpp:1845] Elected as the leading master!
> I0407 22:34:10.527545 29298 master.cpp:1532] Recovering from registrar
> I0407 22:34:10.527889 29298 registrar.cpp:331] Recovering registrar
> I0407 22:34:10.549734 29299 leveldb.cpp:304] Persisting metadata (8 bytes) to 
> leveldb took 28.25177ms
> I0407 22:34:10.549782 29299 replica.cpp:320] Persisted replica status to 
> STARTING
> I0407 22:34:10.550010 29299 recover.cpp:473] Replica is in STARTING status
> I0407 22:34:10.551352 29299 replica.cpp:673] Replica in STARTING status 
> received a broadcasted recover request from (4777)@172.17.0.3:35855
> I0407 22:34:10.551676 29299 recover.cpp:193] Received a recover response from 
> a replica in STARTING status
> I0407