[jira] [Assigned] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues reassigned MESOS-3305: -- Assignee: Kevin Klues > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-3305: --- Shepherd: Bernd Mathiske > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4118) Update Getting Started for Mac OS X El Capitan
Kevin Klues created MESOS-4118: -- Summary: Update Getting Started for Mac OS X El Capitan Key: MESOS-4118 URL: https://issues.apache.org/jira/browse/MESOS-4118 Project: Mesos Issue Type: Documentation Components: documentation Environment: Mac OS X Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor This ticket pertains to the Getting Started guide on the apache mesos website The current instructions for installing on Mac OS X only include instructions for Yosemite. To run after an upgrade to El Capitan requires a trivial (but important) step which is non-obvious -- you have to rerun 'xcode-select --install' after you complete the upgrade. Let's change the heading for installing on Mac OS X to say: Mac OS X Yosemite & El Capitan and then add a comment at the bottom of the section to point out that a rerun of 'xcode-select --install' is necessary after an upgrade from Yosemite to El Capitan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4118) Update Getting Started for Mac OS X El Capitan
[ https://issues.apache.org/jira/browse/MESOS-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4118: --- Description: This ticket pertains to the Getting Started guide on the apache mesos website The current instructions for installing on Mac OS X only include instructions for Yosemite. The instructions to build for El Capitan are identical except in the case of upgrading from Yosemite to El Capitan. To build after an upgrade requires a trivial (but important) step which is non-obvious -- you have to rerun 'xcode-select --install' after you complete the upgrade. Let's change the heading for installing on Mac OS X to say: Mac OS X Yosemite & El Capitan and then add a comment at the bottom of the section to point out that a rerun of 'xcode-select --install' is necessary after an upgrade from Yosemite to El Capitan. was: This ticket pertains to the Getting Started guide on the apache mesos website The current instructions for installing on Mac OS X only include instructions for Yosemite. To run after an upgrade to El Capitan requires a trivial (but important) step which is non-obvious -- you have to rerun 'xcode-select --install' after you complete the upgrade. Let's change the heading for installing on Mac OS X to say: Mac OS X Yosemite & El Capitan and then add a comment at the bottom of the section to point out that a rerun of 'xcode-select --install' is necessary after an upgrade from Yosemite to El Capitan. > Update Getting Started for Mac OS X El Capitan > -- > > Key: MESOS-4118 > URL: https://issues.apache.org/jira/browse/MESOS-4118 > Project: Mesos > Issue Type: Documentation > Components: documentation > Environment: Mac OS X >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere > Original Estimate: 1h > Remaining Estimate: 1h > > This ticket pertains to the Getting Started guide on the apache mesos website > The current instructions for installing on Mac OS X only include instructions > for Yosemite. The instructions to build for El Capitan are identical except > in the case of upgrading from Yosemite to El Capitan. To build after an > upgrade requires a trivial (but important) step which is non-obvious -- you > have to rerun 'xcode-select --install' after you complete the upgrade. > Let's change the heading for installing on Mac OS X to say: > Mac OS X Yosemite & El Capitan > and then add a comment at the bottom of the section to point out that a rerun > of 'xcode-select --install' is necessary after an upgrade from Yosemite to El > Capitan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4125) Use 'git rev-parse --git-dir' in bootstrap instead of simply '.git'
Kevin Klues created MESOS-4125: -- Summary: Use 'git rev-parse --git-dir' in bootstrap instead of simply '.git' Key: MESOS-4125 URL: https://issues.apache.org/jira/browse/MESOS-4125 Project: Mesos Issue Type: Improvement Components: build Environment: All systems Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor This issue relates to the 'bootstrap' file in the top level directory of the mesos tree. When building from git, bootstrap will (among other things) install pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos tree. However the current implementation always assumes that .git exists in the same directory as the bootstrap file. This may not always be true. Most notably, it is not true if the mesos tree is included as a submodule inside another project. When included as a submodule, .git is no longer a directory, but rather a file whose text contains a pointer back to the actual location of the .git folder inside the containing project. To get at this directory, we need to run 'git rev-parse --git-dir' instead of simply assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4125) Use 'git rev-parse --git-dir' in bootstrap instead of simply '.git'
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052920#comment-15052920 ] Kevin Klues commented on MESOS-4125: https://reviews.apache.org/r/41243/ https://reviews.apache.org/r/41244/ > Use 'git rev-parse --git-dir' in bootstrap instead of simply '.git' > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates to the 'bootstrap' file in the top level directory of the > mesos tree. > When building from git, bootstrap will (among other things) install > pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos > tree. However the current implementation always assumes that .git exists in > the same directory as the bootstrap file. This may not always be true. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4125) Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4125: --- Description: This issue relates files where we asume that to the 'bootstrap' file in the top level directory of the mesos tree. When building from git, bootstrap will (among other things) install pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos tree. Moreover, support/pHowever the current implementation always assumes that .git exists in the same directory as the bootstrap file. This may not always be true. Most notably, it is not true if the mesos tree is included as a submodule inside another project. When included as a submodule, .git is no longer a directory, but rather a file whose text contains a pointer back to the actual location of the .git folder inside the containing project. To get at this directory, we need to run 'git rev-parse --git-dir' instead of simply assuming that the local .git is the proper directory. was: This issue relates to the 'bootstrap' file in the top level directory of the mesos tree. When building from git, bootstrap will (among other things) install pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos tree. However the current implementation always assumes that .git exists in the same directory as the bootstrap file. This may not always be true. Most notably, it is not true if the mesos tree is included as a submodule inside another project. When included as a submodule, .git is no longer a directory, but rather a file whose text contains a pointer back to the actual location of the .git folder inside the containing project. To get at this directory, we need to run 'git rev-parse --git-dir' instead of simply assuming that the local .git is the proper directory. > Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates files where we asume that to the 'bootstrap' file in the > top level directory of the mesos tree. > When building from git, bootstrap will (among other things) install > pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos > tree. Moreover, support/pHowever the current implementation always assumes > that .git exists in the same directory as the bootstrap file. This may not > always be true. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4125) Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4125: --- Summary: Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir (was: Use 'git rev-parse --git-dir' in bootstrap instead of simply '.git') > Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates to the 'bootstrap' file in the top level directory of the > mesos tree. > When building from git, bootstrap will (among other things) install > pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos > tree. However the current implementation always assumes that .git exists in > the same directory as the bootstrap file. This may not always be true. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4125) Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4125: --- Description: This issue relates to files where we assume that mesos's '.git' folder is always located in the top level directory of the mesos tree. For example, bootstrap makes this assumption. Specifically, it attempts to install pre-commit and post-rewrite hooks into the hardcoded .git/hooks directory. However, it is not always true that the .git folder is located here. Most notably, it is not true if the mesos tree is included as a submodule inside another project. When included as a submodule, .git is no longer a directory, but rather a file whose text contains a pointer back to the actual location of the .git folder inside the containing project. To get at this directory, we need to run 'git rev-parse --git-dir' instead of simply assuming that the local .git is the proper directory. was: This issue relates files where we asume that to the 'bootstrap' file in the top level directory of the mesos tree. When building from git, bootstrap will (among other things) install pre-commit and post-rewirte hooks into the .git/hooks directory of the mesos tree. Moreover, support/pHowever the current implementation always assumes that .git exists in the same directory as the bootstrap file. This may not always be true. Most notably, it is not true if the mesos tree is included as a submodule inside another project. When included as a submodule, .git is no longer a directory, but rather a file whose text contains a pointer back to the actual location of the .git folder inside the containing project. To get at this directory, we need to run 'git rev-parse --git-dir' instead of simply assuming that the local .git is the proper directory. > Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates to files where we assume that mesos's '.git' folder is > always located in the top level directory of the mesos tree. > For example, bootstrap makes this assumption. Specifically, it attempts to > install pre-commit and post-rewrite hooks into the hardcoded .git/hooks > directory. However, it is not always true that the .git folder is located > here. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053477#comment-15053477 ] Kevin Klues commented on MESOS-3305: On a fresh install of an ubuntu/trusty64 image with vagrant I do not see this issue. Can you confirm this is still an issue with the current Getting Started instructions? I provision with the following script (adapted from http://mesos.apache.org/gettingstarted/): #!/usr/bin/env bash # Update the packages. sudo apt-get update # Install the latest OpenJDK. sudo apt-get install -y openjdk-7-jdk # Install autotools (Only necessary if building from git repository). sudo apt-get install -y autoconf libtool # Install other Mesos dependencies. sudo apt-get -y install build-essential python-dev python-boto libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053651#comment-15053651 ] Kevin Klues commented on MESOS-3842: I am not seeing this issue on master. Can you confirm that it is still a problem? I ran it on vagrant using the vbox centos 7.1 image from here: https://github.com/CommanderK5/packer-centos-template/releases/download/0.7.1/vagrant-centos-7.1.box > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4134) Add note about tunneling in site-docker README
Kevin Klues created MESOS-4134: -- Summary: Add note about tunneling in site-docker README Key: MESOS-4134 URL: https://issues.apache.org/jira/browse/MESOS-4134 Project: Mesos Issue Type: Documentation Components: documentation Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor If we are running the site-docker container on a remote machine, we should set up a tunnel to localhost to view the site locally. The README should explain how to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4134) Add note about tunneling in site-docker README
[ https://issues.apache.org/jira/browse/MESOS-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053741#comment-15053741 ] Kevin Klues commented on MESOS-4134: https://reviews.apache.org/r/41278/ > Add note about tunneling in site-docker README > -- > > Key: MESOS-4134 > URL: https://issues.apache.org/jira/browse/MESOS-4134 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: documentation > > If we are running the site-docker container on a remote machine, we should > set up a tunnel to localhost to view the site locally. The README should > explain how to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4118) Update Getting Started for Mac OS X El Capitan
[ https://issues.apache.org/jira/browse/MESOS-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053769#comment-15053769 ] Kevin Klues commented on MESOS-4118: https://reviews.apache.org/r/41286 > Update Getting Started for Mac OS X El Capitan > -- > > Key: MESOS-4118 > URL: https://issues.apache.org/jira/browse/MESOS-4118 > Project: Mesos > Issue Type: Documentation > Components: documentation > Environment: Mac OS X >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere > Original Estimate: 1h > Remaining Estimate: 1h > > This ticket pertains to the Getting Started guide on the apache mesos website > The current instructions for installing on Mac OS X only include instructions > for Yosemite. The instructions to build for El Capitan are identical except > in the case of upgrading from Yosemite to El Capitan. To build after an > upgrade requires a trivial (but important) step which is non-obvious -- you > have to rerun 'xcode-select --install' after you complete the upgrade. > Let's change the heading for installing on Mac OS X to say: > Mac OS X Yosemite & El Capitan > and then add a comment at the bottom of the section to point out that a rerun > of 'xcode-select --install' is necessary after an upgrade from Yosemite to El > Capitan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3844) getting started documentation has flaws, corrections suggested (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056679#comment-15056679 ] Kevin Klues commented on MESOS-3844: Review: https://reviews.apache.org/r/41364 Review: https://reviews.apache.org/r/41363 Review: https://reviews.apache.org/r/41362 Review: https://reviews.apache.org/r/41361 Review: https://reviews.apache.org/r/41360 Review: https://reviews.apache.org/r/41359 > getting started documentation has flaws, corrections suggested > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3844 > URL: https://issues.apache.org/jira/browse/MESOS-3844 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website, test >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues >Priority: Trivial > Labels: build, documentation, mesosphere > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Getting started documentation, while having great virtues, has room for > improvement: > 1) Documentation is illogical and wrong for this part: > " $ wget http://www.apache.org/dist/mesos/0.25.0/mesos-0.25.0.tar.gz > $ tar -zxf mesos-0.25.0.tar.gz" ...then, later: > "# Install a few utility tools > $ sudo yum install -y tar wget > ..obviously using tar and wget is not possible before installing them. > 2) Although vi is fine for many, utility tools having: > sudo yum install -y tar wget nano > might make editing e.g. the WANDISCO -repo file way easier for newbies. > 3) Advice to launch Mesos with localhost option ( " ./bin/mesos-master.sh > --ip=127.0.0.1 --work_dir=/var/lib/mesos " ) will lead into a state where > Mesos UI can not be reached in port :5050 in a production environment e.g. in > AWS EC2. Mentioning this would help, not hinder deployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056760#comment-15056760 ] Kevin Klues commented on MESOS-3842: I can confirm the problem with bento/centos-7.1. Working on a solution now. > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056862#comment-15056862 ] Kevin Klues commented on MESOS-3842: Even if we did this, the bug still doesn't allow svn to be installed properly. It fails on the libserf-1 dependency. > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056867#comment-15056867 ] Kevin Klues commented on MESOS-3842: [vagrant@mesos-centos-7 ~]$ sudo yum install subversion Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirror.san.fastserv.com * updates: mirror.lax.hugeserver.com Resolving Dependencies --> Running transaction check ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: apr-util >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: apr >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libapr-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libaprutil-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Running transaction check ---> Package apr.x86_64 0:1.4.8-3.el7 will be installed ---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Finished Dependency Resolution Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) Requires: libserf-1.so.0()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-3842: --- Comment: was deleted (was: [vagrant@mesos-centos-7 ~]$ sudo yum install subversion Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirror.san.fastserv.com * updates: mirror.lax.hugeserver.com Resolving Dependencies --> Running transaction check ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: apr-util >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: apr >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libapr-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libaprutil-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Running transaction check ---> Package apr.x86_64 0:1.4.8-3.el7 will be installed ---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Finished Dependency Resolution Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) Requires: libserf-1.so.0()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest) > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056868#comment-15056868 ] Kevin Klues commented on MESOS-3842: [vagrant@mesos-centos-7 ~]$ sudo yum install subversion Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirror.san.fastserv.com * updates: mirror.lax.hugeserver.com Resolving Dependencies --> Running transaction check ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: apr-util >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: apr >= 1.2.7 for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libapr-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libaprutil-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Running transaction check ---> Package apr.x86_64 0:1.4.8-3.el7 will be installed ---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed ---> Package subversion.x86_64 0:1.9.2-1 will be installed --> Processing Dependency: libserf-1.so.0()(64bit) for package: subversion-1.9.2-1.x86_64 --> Finished Dependency Resolution Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) Requires: libserf-1.so.0()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3842) getting started documentation following Mesos 0.25 build fails for CentOS7 (http://mesos.apache.org/gettingstarted/)
[ https://issues.apache.org/jira/browse/MESOS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056989#comment-15056989 ] Kevin Klues commented on MESOS-3842: https://reviews.apache.org/r/41371/ > getting started documentation following Mesos 0.25 build fails for CentOS7 > (http://mesos.apache.org/gettingstarted/) > > > Key: MESOS-3842 > URL: https://issues.apache.org/jira/browse/MESOS-3842 > Project: Mesos > Issue Type: Documentation > Components: documentation, project website >Affects Versions: 0.25.0 > Environment: CentOS 7 AWS Linux image: AWS EC2 MarketPlace CentOS 7 > (x86_64) with Updates HVM (a t2.medium instance) >Reporter: Manne Laukkanen >Assignee: Kevin Klues > Labels: build, documentation, mesosphere > Original Estimate: 3h > Remaining Estimate: 3h > > WANdisco SVN repo file usage leads to failure of build process with error, so > usage of it should be 1) discouraged 2) replaced with a working solution > Proceeding according to documentation at > http://mesos.apache.org/gettingstarted/: > # 'Mesos > 0.21.0' requires 'subversion > 1.8' devel package, which is > # not available in the default repositories. > # Add the WANdisco SVN repo file: '/etc/yum.repos.d/wandisco-svn.repo' with > content: > [WANdiscoSVN] > name=WANdisco SVN Repo 1.9 > enabled=1 > baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/ > gpgcheck=1 > gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco > ...we do as is described, then proceed to next step, which is > "# Install essential development tools." > sudo yum groupinstall -y "Development Tools" > ...the added WANDISCO -repo causes failed building process with error: > Error: Package: subversion-1.9.2-1.x86_64 (WANdiscoSVN) >Requires: libserf-1.so.0()(64bit) > - we end up with e.g. no build tools to proceed with, so process fails, > Mesos can not be built according to instructions (e.g. no C-compiler in > path...) > Interestingly, building with aforementioned instructions (with some > modifications mentioned in ticket MESOS-3844) was successful without errors > justa a few days ago on 30 Oct 2015. WANDISCO repo breakage? > No changes to building machine image (the CentOS7 image) nor machine itself > (t2.medium EC2 instance) were made in between attempts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057011#comment-15057011 ] Kevin Klues commented on MESOS-3305: Can you please confirm that you still see this issue? > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057011#comment-15057011 ] Kevin Klues edited comment on MESOS-3305 at 12/15/15 12:15 AM: --- Can you please confirm that you still see this issue? I need to be able to reproduce the issue in order to fix it properly. was (Author: klueska): Can you please confirm that you still see this issue? > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3954) The documentation should recommend an updated systemd for centos 7.
[ https://issues.apache.org/jira/browse/MESOS-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057065#comment-15057065 ] Kevin Klues commented on MESOS-3954: https://reviews.apache.org/r/41372/ > The documentation should recommend an updated systemd for centos 7. > --- > > Key: MESOS-3954 > URL: https://issues.apache.org/jira/browse/MESOS-3954 > Project: Mesos > Issue Type: Documentation > Components: documentation >Reporter: Till Toenshoff >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere > > After installing a plain centos 7, some Mesos tests kept failing due to > MESOS-3352. > We should try to minimize such experience for our users by e.g. adding the > need for an explicit systemd update on this distribution (and maybe others). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057122#comment-15057122 ] Kevin Klues commented on MESOS-3305: I figured it out. The default ubuntu/trusty64 image on atlas now comes preinstalled with 'libsasl2-modules', so I wasn't running into this issue. I will add it as a dependence in the 'System Requirements' document in case people don't happen to use this particular image. > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3305) Getting Started docs for Ubuntu needs reference to libsasl2-modules
[ https://issues.apache.org/jira/browse/MESOS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057406#comment-15057406 ] Kevin Klues commented on MESOS-3305: https://reviews.apache.org/r/41383/ > Getting Started docs for Ubuntu needs reference to libsasl2-modules > --- > > Key: MESOS-3305 > URL: https://issues.apache.org/jira/browse/MESOS-3305 > Project: Mesos > Issue Type: Documentation > Components: documentation >Affects Versions: 0.23.0 > Environment: Ubuntu 14.04 >Reporter: Andrew A Smith >Assignee: Kevin Klues >Priority: Minor > Labels: documentation, mesosphere, newbie > > Following the Getting Started docs leads to an error during configure, due to > a missing dependency. > Error during configure: > checking SASL CRAM-MD5 support... configure: error: no > --- > We need CRAM-MD5 support for SASL authentication. > --- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4180) Add flags to post_reviews.py to update summary and description.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4180: --- Summary: Add flags to post_reviews.py to update summary and description. (was: Added flags to post_reviews.py to update summary and description.) > Add flags to post_reviews.py to update summary and description. > --- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with some simple > flags to the 'rbt' command we can force the review's summary / description to > be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4180) Added flags to post_reviews.py to update summary and description.
Kevin Klues created MESOS-4180: -- Summary: Added flags to post_reviews.py to update summary and description. Key: MESOS-4180 URL: https://issues.apache.org/jira/browse/MESOS-4180 Project: Mesos Issue Type: Improvement Components: general Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor If you amend a commit message and post it to reviewboard via the support/post_reviews.py script, then the summary / description on reviewboard does not get updated between subsequent revisions. The only way to update these is to modify them directly on the webpage. However, with some simple flags to the 'rbt' command we can force the review's summary / description to be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4180) Add flags to post_reviews.py to update summary and description.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058935#comment-15058935 ] Kevin Klues commented on MESOS-4180: https://reviews.apache.org/r/41411/ > Add flags to post_reviews.py to update summary and description. > --- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with some simple > flags to the 'rbt' command we can force the review's summary / description to > be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4180) Add flags to post_reviews.py to update summary and description.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4180: --- Description: If you amend a commit message and post it to reviewboard via the support/post_reviews.py script, then the summary / description on reviewboard does not get updated between subsequent revisions. The only way to update these is to modify them directly on the webpage. However, with a simple directive in the .reviewboardrc file we can force the review's summary / description to be updated to the text in the commit message. (was: If you amend a commit message and post it to reviewboard via the support/post_reviews.py script, then the summary / description on reviewboard does not get updated between subsequent revisions. The only way to update these is to modify them directly on the webpage. However, with some simple flags to the 'rbt' command we can force the review's summary / description to be updated to the text in the commit message. ) > Add flags to post_reviews.py to update summary and description. > --- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with a simple > directive in the .reviewboardrc file we can force the review's summary / > description to be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4180) Add flags to update summary and description in updated patches for review.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4180: --- Summary: Add flags to update summary and description in updated patches for review. (was: Add flags to post_reviews.py to update summary and description.) > Add flags to update summary and description in updated patches for review. > -- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with a simple > directive in the .reviewboardrc file we can force the review's summary / > description to be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4184) Jenkins builds for Centos fail with missing 'which' utility and incorrect 'java.home'
Kevin Klues created MESOS-4184: -- Summary: Jenkins builds for Centos fail with missing 'which' utility and incorrect 'java.home' Key: MESOS-4184 URL: https://issues.apache.org/jira/browse/MESOS-4184 Project: Mesos Issue Type: Bug Components: jenkins Environment: centos 7 Reporter: Kevin Klues Assignee: Kevin Klues Jenkins builds are now consistently failing for centos 7, withe the failure: checking value of Java system property 'java.home'... /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre configure: error: could not guess JAVA_HOME They also fail early on during 'bootstrap' with a missing 'which' command. The solution is to update support/docker_build.sh to install 'which' as well as make sure the proper versions of java are installed during the installation process. The problem here is that This is that we install maven BEFORE installing java-1.7.0-openjdk-devel, causing maven to pull in a dependency on java-1.8.0-openjdk. This causes problems with finding the proper java.home in our mesos/configure script because of the mismatch between the most up to date jre (1.8.0) and the most up to date development tools (1.7.0). We can either update the script to pull in the 1.8 devel tools or move our dependence on maven until AFTER our installation of java-1.7.0-openjdk-devel. Unclear what the best solution is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4184) Jenkins builds for Centos fail with missing 'which' utility and incorrect 'java.home'
[ https://issues.apache.org/jira/browse/MESOS-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4184: --- Description: Jenkins builds are now consistently failing for centos 7, withe the failure: checking value of Java system property 'java.home'... /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre configure: error: could not guess JAVA_HOME They also fail early on during 'bootstrap' with a missing 'which' command. The solution is to update support/docker_build.sh to install 'which' as well as make sure the proper versions of java are installed during the installation process. The problem here is that we install maven BEFORE installing java-1.7.0-openjdk-devel, causing maven to pull in a dependency on java-1.8.0-openjdk. This causes problems with finding the proper java.home in our mesos/configure script because of the mismatch between the most up to date jre (1.8.0) and the most up to date development tools (1.7.0). We can either update the script to pull in the 1.8 devel tools or move our dependence on maven until AFTER our installation of java-1.7.0-openjdk-devel. Unclear what the best solution is. was: Jenkins builds are now consistently failing for centos 7, withe the failure: checking value of Java system property 'java.home'... /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre configure: error: could not guess JAVA_HOME They also fail early on during 'bootstrap' with a missing 'which' command. The solution is to update support/docker_build.sh to install 'which' as well as make sure the proper versions of java are installed during the installation process. The problem here is that This is that we install maven BEFORE installing java-1.7.0-openjdk-devel, causing maven to pull in a dependency on java-1.8.0-openjdk. This causes problems with finding the proper java.home in our mesos/configure script because of the mismatch between the most up to date jre (1.8.0) and the most up to date development tools (1.7.0). We can either update the script to pull in the 1.8 devel tools or move our dependence on maven until AFTER our installation of java-1.7.0-openjdk-devel. Unclear what the best solution is. > Jenkins builds for Centos fail with missing 'which' utility and incorrect > 'java.home' > - > > Key: MESOS-4184 > URL: https://issues.apache.org/jira/browse/MESOS-4184 > Project: Mesos > Issue Type: Bug > Components: jenkins > Environment: centos 7 >Reporter: Kevin Klues >Assignee: Kevin Klues > > Jenkins builds are now consistently failing for centos 7, withe the failure: > checking value of Java system property 'java.home'... > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre > configure: error: could not guess JAVA_HOME > They also fail early on during 'bootstrap' with a missing 'which' command. > The solution is to update support/docker_build.sh to install 'which' as well > as make sure the proper versions of java are installed during the > installation process. > The problem here is that we install maven BEFORE installing > java-1.7.0-openjdk-devel, causing maven to pull in a dependency on > java-1.8.0-openjdk. This causes problems with finding the proper java.home in > our mesos/configure script because of the mismatch between the most up to > date jre (1.8.0) and the most up to date development tools (1.7.0). We can > either update the script to pull in the 1.8 devel tools or move our > dependence on maven until AFTER our installation of java-1.7.0-openjdk-devel. > Unclear what the best solution is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4184) Jenkins builds for Centos fail with missing 'which' utility and incorrect 'java.home'
[ https://issues.apache.org/jira/browse/MESOS-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061251#comment-15061251 ] Kevin Klues commented on MESOS-4184: https://reviews.apache.org/r/41475/ > Jenkins builds for Centos fail with missing 'which' utility and incorrect > 'java.home' > - > > Key: MESOS-4184 > URL: https://issues.apache.org/jira/browse/MESOS-4184 > Project: Mesos > Issue Type: Bug > Components: jenkins > Environment: centos 7 >Reporter: Kevin Klues >Assignee: Kevin Klues > > Jenkins builds are now consistently failing for centos 7, withe the failure: > checking value of Java system property 'java.home'... > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64/jre > configure: error: could not guess JAVA_HOME > They also fail early on during 'bootstrap' with a missing 'which' command. > The solution is to update support/docker_build.sh to install 'which' as well > as make sure the proper versions of java are installed during the > installation process. > The problem here is that we install maven BEFORE installing > java-1.7.0-openjdk-devel, causing maven to pull in a dependency on > java-1.8.0-openjdk. This causes problems with finding the proper java.home in > our mesos/configure script because of the mismatch between the most up to > date jre (1.8.0) and the most up to date development tools (1.7.0). We can > either update the script to pull in the 1.8 devel tools or move our > dependence on maven until AFTER our installation of java-1.7.0-openjdk-devel. > Unclear what the best solution is. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4185) Revisit the "System Requirements" for all systems in the "Getting Started" guide
Kevin Klues created MESOS-4185: -- Summary: Revisit the "System Requirements" for all systems in the "Getting Started" guide Key: MESOS-4185 URL: https://issues.apache.org/jira/browse/MESOS-4185 Project: Mesos Issue Type: Documentation Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor The "System Requirements" section of our "Getting Started" guide needs an overhaul. Much of the information is outdated, and could likely be distilled down to a simpler set of dependencies (especially for Centos 6.6 and Centos 7.1). We should take a good hard look at these and see if all of the dependencies listed are necessary anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3307) Configurable size of completed task / framework history
[
https://issues.apache.org/jira/browse/MESOS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15086598#comment-15086598
]
Kevin Klues commented on MESOS-3307:
/state-summary is not listed as an endpoint in /help. How is the list of
endpoints under /help generated?
> Configurable size of completed task / framework history
> ---
>
> Key: MESOS-3307
> URL: https://issues.apache.org/jira/browse/MESOS-3307
> Project: Mesos
> Issue Type: Bug
>Reporter: Ian Babrou
>Assignee: Kevin Klues
> Labels: mesosphere
>
> We try to make Mesos work with multiple frameworks and mesos-dns at the same
> time. The goal is to have set of frameworks per team / project on a single
> Mesos cluster.
> At this point our mesos state.json is at 4mb and it takes a while to
> assembly. 5 mesos-dns instances hit state.json every 5 seconds, effectively
> pushing mesos-master CPU usage through the roof. It's at 100%+ all the time.
> Here's the problem:
> {noformat}
> mesos λ curl -s http://mesos-master:5050/master/state.json | jq
> .frameworks[].completed_tasks[].framework_id | sort | uniq -c | sort -n
>1 "20150606-001827-252388362-5050-5982-0003"
> 16 "20150606-001827-252388362-5050-5982-0005"
> 18 "20150606-001827-252388362-5050-5982-0029"
> 73 "20150606-001827-252388362-5050-5982-0007"
> 141 "20150606-001827-252388362-5050-5982-0009"
> 154 "20150820-154817-302720010-5050-15320-"
> 289 "20150606-001827-252388362-5050-5982-0004"
> 510 "20150606-001827-252388362-5050-5982-0012"
> 666 "20150606-001827-252388362-5050-5982-0028"
> 923 "20150116-002612-269165578-5050-32204-0003"
> 1000 "20150606-001827-252388362-5050-5982-0001"
> 1000 "20150606-001827-252388362-5050-5982-0006"
> 1000 "20150606-001827-252388362-5050-5982-0010"
> 1000 "20150606-001827-252388362-5050-5982-0011"
> 1000 "20150606-001827-252388362-5050-5982-0027"
> mesos λ fgrep 1000 -r src/master
> src/master/constants.cpp:const size_t MAX_REMOVED_SLAVES = 10;
> src/master/constants.cpp:const uint32_t MAX_COMPLETED_TASKS_PER_FRAMEWORK =
> 1000;
> {noformat}
> Active tasks are just 6% of state.json response:
> {noformat}
> mesos λ cat ~/temp/mesos-state.json | jq -c . | wc
>1 14796 4138942
> mesos λ cat ~/temp/mesos-state.json | jq .frameworks[].tasks | jq -c . | wc
> 16 37 252774
> {noformat}
> I see four options that can improve the situation:
> 1. Add query string param to exclude completed tasks from state.json and use
> it in mesos-dns and similar tools. There is no need for mesos-dns to know
> about completed tasks, it's just extra load on master and mesos-dns.
> 2. Make history size configurable.
> 3. Make JSON serialization faster. With 1s of tasks even without history
> it would take a lot of time to serialize tasks for mesos-dns. Doing it every
> 60 seconds instead of every 5 seconds isn't really an option.
> 4. Create event bus for mesos master. Marathon has it and it'd be nice to
> have it in Mesos. This way mesos-dns could avoid polling master state and
> switch to listening for events.
> All can be done independently.
> Note to mesosphere folks: please start distributing debug symbols with your
> distribution. I was asking for it for a while and it is really helpful:
> https://github.com/mesosphere/marathon/issues/1497#issuecomment-104182501
> Perf report for leading master:
> !http://i.imgur.com/iz7C3o0.png!
> I'm on 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4307) Expand the "Getting Started" installation instructions
[ https://issues.apache.org/jira/browse/MESOS-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15087790#comment-15087790 ] Kevin Klues commented on MESOS-4307: This has overlap with https://issues.apache.org/jira/browse/MESOS-4185 > Expand the "Getting Started" installation instructions > -- > > Key: MESOS-4307 > URL: https://issues.apache.org/jira/browse/MESOS-4307 > Project: Mesos > Issue Type: Improvement >Reporter: Greg Mann > Labels: documentation, mesosphere, testing > > The "Getting Started" documentation currently contains basic instructions to > prepare several platforms for compilation and installation of Mesos. However, > these instructions are not sufficient to run and pass all tests in the test > suite, using all configuration options. The installation instructions should > be made comprehensive in this respect. > It may also be desirable to provide scripts that have been verified to > prepare a particular base OS to build, install, and test Mesos. This would be > very useful for both developers and users of Mesos. > Note that using some features on some platforms requires the installation of > software packages from sources that may not be completely reliable in the > long-term; for example, packages which are maintained as personal projects of > individuals. This should be noted in the instructions accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3307) Configurable size of completed task / framework history
[
https://issues.apache.org/jira/browse/MESOS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088379#comment-15088379
]
Kevin Klues commented on MESOS-3307:
Yeah, me and Ben Mahler just chatted about it and decided the same. I am
working on fixing up Felix's pull request to adhere to our code standards /
pass through review board and will push it through later this afternoon.
> Configurable size of completed task / framework history
> ---
>
> Key: MESOS-3307
> URL: https://issues.apache.org/jira/browse/MESOS-3307
> Project: Mesos
> Issue Type: Bug
>Reporter: Ian Babrou
>Assignee: Kevin Klues
> Labels: mesosphere
>
> We try to make Mesos work with multiple frameworks and mesos-dns at the same
> time. The goal is to have set of frameworks per team / project on a single
> Mesos cluster.
> At this point our mesos state.json is at 4mb and it takes a while to
> assembly. 5 mesos-dns instances hit state.json every 5 seconds, effectively
> pushing mesos-master CPU usage through the roof. It's at 100%+ all the time.
> Here's the problem:
> {noformat}
> mesos λ curl -s http://mesos-master:5050/master/state.json | jq
> .frameworks[].completed_tasks[].framework_id | sort | uniq -c | sort -n
>1 "20150606-001827-252388362-5050-5982-0003"
> 16 "20150606-001827-252388362-5050-5982-0005"
> 18 "20150606-001827-252388362-5050-5982-0029"
> 73 "20150606-001827-252388362-5050-5982-0007"
> 141 "20150606-001827-252388362-5050-5982-0009"
> 154 "20150820-154817-302720010-5050-15320-"
> 289 "20150606-001827-252388362-5050-5982-0004"
> 510 "20150606-001827-252388362-5050-5982-0012"
> 666 "20150606-001827-252388362-5050-5982-0028"
> 923 "20150116-002612-269165578-5050-32204-0003"
> 1000 "20150606-001827-252388362-5050-5982-0001"
> 1000 "20150606-001827-252388362-5050-5982-0006"
> 1000 "20150606-001827-252388362-5050-5982-0010"
> 1000 "20150606-001827-252388362-5050-5982-0011"
> 1000 "20150606-001827-252388362-5050-5982-0027"
> mesos λ fgrep 1000 -r src/master
> src/master/constants.cpp:const size_t MAX_REMOVED_SLAVES = 10;
> src/master/constants.cpp:const uint32_t MAX_COMPLETED_TASKS_PER_FRAMEWORK =
> 1000;
> {noformat}
> Active tasks are just 6% of state.json response:
> {noformat}
> mesos λ cat ~/temp/mesos-state.json | jq -c . | wc
>1 14796 4138942
> mesos λ cat ~/temp/mesos-state.json | jq .frameworks[].tasks | jq -c . | wc
> 16 37 252774
> {noformat}
> I see four options that can improve the situation:
> 1. Add query string param to exclude completed tasks from state.json and use
> it in mesos-dns and similar tools. There is no need for mesos-dns to know
> about completed tasks, it's just extra load on master and mesos-dns.
> 2. Make history size configurable.
> 3. Make JSON serialization faster. With 1s of tasks even without history
> it would take a lot of time to serialize tasks for mesos-dns. Doing it every
> 60 seconds instead of every 5 seconds isn't really an option.
> 4. Create event bus for mesos master. Marathon has it and it'd be nice to
> have it in Mesos. This way mesos-dns could avoid polling master state and
> switch to listening for events.
> All can be done independently.
> Note to mesosphere folks: please start distributing debug symbols with your
> distribution. I was asking for it for a while and it is really helpful:
> https://github.com/mesosphere/marathon/issues/1497#issuecomment-104182501
> Perf report for leading master:
> !http://i.imgur.com/iz7C3o0.png!
> I'm on 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3307) Configurable size of completed task / framework history
[
https://issues.apache.org/jira/browse/MESOS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088554#comment-15088554
]
Kevin Klues commented on MESOS-3307:
I have submitted a patch for review based on Felix's pull request (with some
modifications):
https://reviews.apache.org/r/42053/
This patch adds configure flags for setting the buffer size of the completed
frameworks and tasks_per_framework variables for the state.json (and related)
endpoints. This combined with MESOS-2353 for significantly reducing the time
it takes to generate state.json *should* resolve the ticket addressed here.
However, in the long term things like mesos-dns *should* use the "Mesos Master
Event Streaming" API that Alexander Rukletsov and others are working once it is
completed. This will make bandaid solutions like this one unnecessary.
Also, keep in mind, the use of these newly introduced flags will only help if
you are in charge of running your master configuration. If you are using
something like the Mesosphere DCOS to automatically set up your master/agent
configuration, then these flags will likely not be of much help because their
default values will remain as they were before.
> Configurable size of completed task / framework history
> ---
>
> Key: MESOS-3307
> URL: https://issues.apache.org/jira/browse/MESOS-3307
> Project: Mesos
> Issue Type: Bug
>Reporter: Ian Babrou
>Assignee: Kevin Klues
> Labels: mesosphere
>
> We try to make Mesos work with multiple frameworks and mesos-dns at the same
> time. The goal is to have set of frameworks per team / project on a single
> Mesos cluster.
> At this point our mesos state.json is at 4mb and it takes a while to
> assembly. 5 mesos-dns instances hit state.json every 5 seconds, effectively
> pushing mesos-master CPU usage through the roof. It's at 100%+ all the time.
> Here's the problem:
> {noformat}
> mesos λ curl -s http://mesos-master:5050/master/state.json | jq
> .frameworks[].completed_tasks[].framework_id | sort | uniq -c | sort -n
>1 "20150606-001827-252388362-5050-5982-0003"
> 16 "20150606-001827-252388362-5050-5982-0005"
> 18 "20150606-001827-252388362-5050-5982-0029"
> 73 "20150606-001827-252388362-5050-5982-0007"
> 141 "20150606-001827-252388362-5050-5982-0009"
> 154 "20150820-154817-302720010-5050-15320-"
> 289 "20150606-001827-252388362-5050-5982-0004"
> 510 "20150606-001827-252388362-5050-5982-0012"
> 666 "20150606-001827-252388362-5050-5982-0028"
> 923 "20150116-002612-269165578-5050-32204-0003"
> 1000 "20150606-001827-252388362-5050-5982-0001"
> 1000 "20150606-001827-252388362-5050-5982-0006"
> 1000 "20150606-001827-252388362-5050-5982-0010"
> 1000 "20150606-001827-252388362-5050-5982-0011"
> 1000 "20150606-001827-252388362-5050-5982-0027"
> mesos λ fgrep 1000 -r src/master
> src/master/constants.cpp:const size_t MAX_REMOVED_SLAVES = 10;
> src/master/constants.cpp:const uint32_t MAX_COMPLETED_TASKS_PER_FRAMEWORK =
> 1000;
> {noformat}
> Active tasks are just 6% of state.json response:
> {noformat}
> mesos λ cat ~/temp/mesos-state.json | jq -c . | wc
>1 14796 4138942
> mesos λ cat ~/temp/mesos-state.json | jq .frameworks[].tasks | jq -c . | wc
> 16 37 252774
> {noformat}
> I see four options that can improve the situation:
> 1. Add query string param to exclude completed tasks from state.json and use
> it in mesos-dns and similar tools. There is no need for mesos-dns to know
> about completed tasks, it's just extra load on master and mesos-dns.
> 2. Make history size configurable.
> 3. Make JSON serialization faster. With 1s of tasks even without history
> it would take a lot of time to serialize tasks for mesos-dns. Doing it every
> 60 seconds instead of every 5 seconds isn't really an option.
> 4. Create event bus for mesos master. Marathon has it and it'd be nice to
> have it in Mesos. This way mesos-dns could avoid polling master state and
> switch to listening for events.
> All can be done independently.
> Note to mesosphere folks: please start distributing debug symbols with your
> distribution. I was asking for it for a while and it is really helpful:
> https://github.com/mesosphere/marathon/issues/1497#issuecomment-104182501
> Perf report for leading master:
> !http://i.imgur.com/iz7C3o0.png!
> I'm on 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4125) Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092495#comment-15092495 ] Kevin Klues commented on MESOS-4125: Sorry for the delay. Ive been on vacation. Working on an updated patch now. > Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates to files where we assume that mesos's '.git' folder is > always located in the top level directory of the mesos tree. > For example, bootstrap makes this assumption. Specifically, it attempts to > install pre-commit and post-rewrite hooks into the hardcoded .git/hooks > directory. However, it is not always true that the .git folder is located > here. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3307) Configurable size of completed task / framework history
[
https://issues.apache.org/jira/browse/MESOS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095067#comment-15095067
]
Kevin Klues commented on MESOS-3307:
Here are the reviews out for this:
https://reviews.apache.org/r/42053/
https://reviews.apache.org/r/42212/
> Configurable size of completed task / framework history
> ---
>
> Key: MESOS-3307
> URL: https://issues.apache.org/jira/browse/MESOS-3307
> Project: Mesos
> Issue Type: Bug
>Reporter: Ian Babrou
>Assignee: Kevin Klues
> Labels: mesosphere
>
> We try to make Mesos work with multiple frameworks and mesos-dns at the same
> time. The goal is to have set of frameworks per team / project on a single
> Mesos cluster.
> At this point our mesos state.json is at 4mb and it takes a while to
> assembly. 5 mesos-dns instances hit state.json every 5 seconds, effectively
> pushing mesos-master CPU usage through the roof. It's at 100%+ all the time.
> Here's the problem:
> {noformat}
> mesos λ curl -s http://mesos-master:5050/master/state.json | jq
> .frameworks[].completed_tasks[].framework_id | sort | uniq -c | sort -n
>1 "20150606-001827-252388362-5050-5982-0003"
> 16 "20150606-001827-252388362-5050-5982-0005"
> 18 "20150606-001827-252388362-5050-5982-0029"
> 73 "20150606-001827-252388362-5050-5982-0007"
> 141 "20150606-001827-252388362-5050-5982-0009"
> 154 "20150820-154817-302720010-5050-15320-"
> 289 "20150606-001827-252388362-5050-5982-0004"
> 510 "20150606-001827-252388362-5050-5982-0012"
> 666 "20150606-001827-252388362-5050-5982-0028"
> 923 "20150116-002612-269165578-5050-32204-0003"
> 1000 "20150606-001827-252388362-5050-5982-0001"
> 1000 "20150606-001827-252388362-5050-5982-0006"
> 1000 "20150606-001827-252388362-5050-5982-0010"
> 1000 "20150606-001827-252388362-5050-5982-0011"
> 1000 "20150606-001827-252388362-5050-5982-0027"
> mesos λ fgrep 1000 -r src/master
> src/master/constants.cpp:const size_t MAX_REMOVED_SLAVES = 10;
> src/master/constants.cpp:const uint32_t MAX_COMPLETED_TASKS_PER_FRAMEWORK =
> 1000;
> {noformat}
> Active tasks are just 6% of state.json response:
> {noformat}
> mesos λ cat ~/temp/mesos-state.json | jq -c . | wc
>1 14796 4138942
> mesos λ cat ~/temp/mesos-state.json | jq .frameworks[].tasks | jq -c . | wc
> 16 37 252774
> {noformat}
> I see four options that can improve the situation:
> 1. Add query string param to exclude completed tasks from state.json and use
> it in mesos-dns and similar tools. There is no need for mesos-dns to know
> about completed tasks, it's just extra load on master and mesos-dns.
> 2. Make history size configurable.
> 3. Make JSON serialization faster. With 1s of tasks even without history
> it would take a lot of time to serialize tasks for mesos-dns. Doing it every
> 60 seconds instead of every 5 seconds isn't really an option.
> 4. Create event bus for mesos master. Marathon has it and it'd be nice to
> have it in Mesos. This way mesos-dns could avoid polling master state and
> switch to listening for events.
> All can be done independently.
> Note to mesosphere folks: please start distributing debug symbols with your
> distribution. I was asking for it for a while and it is really helpful:
> https://github.com/mesosphere/marathon/issues/1497#issuecomment-104182501
> Perf report for leading master:
> !http://i.imgur.com/iz7C3o0.png!
> I'm on 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4348) GMock warning in HookTest.VerifySlaveRunTaskHook, HookTest.VerifySlaveTaskStatusDecorator
[
https://issues.apache.org/jira/browse/MESOS-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095106#comment-15095106
]
Kevin Klues commented on MESOS-4348:
You just need a:
EXPECT_CALL(exec, shutdown(_))
.Times(AtMost(1));
just before the calls to:
driver.stop();
driver.join();
> GMock warning in HookTest.VerifySlaveRunTaskHook,
> HookTest.VerifySlaveTaskStatusDecorator
> -
>
> Key: MESOS-4348
> URL: https://issues.apache.org/jira/browse/MESOS-4348
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Reporter: Neil Conway
>Priority: Minor
> Labels: mesosphere, tests
>
> {noformat}
> [ RUN ] HookTest.VerifySlaveRunTaskHook
> GMOCK WARNING:
> Uninteresting mock function call - returning directly.
> Function call: shutdown(0x7ff079cb2420)
> Stack trace:
> [ OK ] HookTest.VerifySlaveRunTaskHook (51 ms)
> [ RUN ] HookTest.VerifySlaveTaskStatusDecorator
> GMOCK WARNING:
> Uninteresting mock function call - returning directly.
> Function call: shutdown(0x7ff079cbb790)
> Stack trace:
> [ OK ] HookTest.VerifySlaveTaskStatusDecorator (54 ms)
> {noformat}
> Occurs non-deterministically for me. OSX 10.10.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4180) Add flags to update summary and description in updated patches for review.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097049#comment-15097049 ] Kevin Klues commented on MESOS-4180: A follow on patch to make sure that the Review URL does not get submitted by post-reviews.py can be found here: https://reviews.apache.org/r/42266/ > Add flags to update summary and description in updated patches for review. > -- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with a simple > directive in the .reviewboardrc file we can force the review's summary / > description to be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4361) Cleanup post_reviews.py and appy_reviews.py
Kevin Klues created MESOS-4361: -- Summary: Cleanup post_reviews.py and appy_reviews.py Key: MESOS-4361 URL: https://issues.apache.org/jira/browse/MESOS-4361 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Priority: Minor These files could use a massive overhaul to extract key functionality into helper functions and call them from some primary flow of logic. They also share alot of functionality that could be shared between them through a common import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4361) Cleanup post_reviews.py and apply_reviews.py
[ https://issues.apache.org/jira/browse/MESOS-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4361: --- Summary: Cleanup post_reviews.py and apply_reviews.py (was: Cleanup post_reviews.py and appy_reviews.py) > Cleanup post_reviews.py and apply_reviews.py > > > Key: MESOS-4361 > URL: https://issues.apache.org/jira/browse/MESOS-4361 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Priority: Minor > Labels: mesosphere, review > > These files could use a massive overhaul to extract key functionality into > helper functions and call them from some primary flow of logic. They also > share alot of functionality that could be shared between them through a > common import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4361) Cleanup post_reviews.py and apply_reviews.py
[ https://issues.apache.org/jira/browse/MESOS-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4361: --- Labels: mesosphere review (was: ) > Cleanup post_reviews.py and apply_reviews.py > > > Key: MESOS-4361 > URL: https://issues.apache.org/jira/browse/MESOS-4361 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Priority: Minor > Labels: mesosphere, review > > These files could use a massive overhaul to extract key functionality into > helper functions and call them from some primary flow of logic. They also > share alot of functionality that could be shared between them through a > common import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4125) Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir
[ https://issues.apache.org/jira/browse/MESOS-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4125: --- Sprint: Mesosphere Sprint 26 > Use 'git rev-parse --git-dir' instead of assuming '.git' in top dir > --- > > Key: MESOS-4125 > URL: https://issues.apache.org/jira/browse/MESOS-4125 > Project: Mesos > Issue Type: Improvement > Components: build > Environment: All systems >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: bootstrap, build, mesosphere > > This issue relates to files where we assume that mesos's '.git' folder is > always located in the top level directory of the mesos tree. > For example, bootstrap makes this assumption. Specifically, it attempts to > install pre-commit and post-rewrite hooks into the hardcoded .git/hooks > directory. However, it is not always true that the .git folder is located > here. > Most notably, it is not true if the mesos tree is included as a submodule > inside another project. When included as a submodule, .git is no longer a > directory, but rather a file whose text contains a pointer back to the actual > location of the .git folder inside the containing project. To get at this > directory, we need to run 'git rev-parse --git-dir' instead of simply > assuming that the local .git is the proper directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4180) Add flags to update summary and description in updated patches for review.
[ https://issues.apache.org/jira/browse/MESOS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4180: --- Sprint: Mesosphere Sprint 26 > Add flags to update summary and description in updated patches for review. > -- > > Key: MESOS-4180 > URL: https://issues.apache.org/jira/browse/MESOS-4180 > Project: Mesos > Issue Type: Improvement > Components: general >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: reviewboard > > If you amend a commit message and post it to reviewboard via the > support/post_reviews.py script, then the summary / description on reviewboard > does not get updated between subsequent revisions. The only way to update > these is to modify them directly on the webpage. However, with a simple > directive in the .reviewboardrc file we can force the review's summary / > description to be updated to the text in the commit message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4374) Newer versions of git don't support the new --git-common-dir flag used in bootstrap and post-reviews.py
Kevin Klues created MESOS-4374: -- Summary: Newer versions of git don't support the new --git-common-dir flag used in bootstrap and post-reviews.py Key: MESOS-4374 URL: https://issues.apache.org/jira/browse/MESOS-4374 Project: Mesos Issue Type: Bug Reporter: Kevin Klues Assignee: Kevin Klues The newly introduced way of finding the .git directory via --git-common-dir is only supported on newer versions of git. Fallback to the older --git-dir method if --git-common-dir is not supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4374) Newer versions of git don't support the new --git-common-dir flag used in bootstrap and post-reviews.py
[ https://issues.apache.org/jira/browse/MESOS-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15098373#comment-15098373 ] Kevin Klues commented on MESOS-4374: Under review at: https://reviews.apache.org/r/42309/ > Newer versions of git don't support the new --git-common-dir flag used in > bootstrap and post-reviews.py > --- > > Key: MESOS-4374 > URL: https://issues.apache.org/jira/browse/MESOS-4374 > Project: Mesos > Issue Type: Bug >Reporter: Kevin Klues >Assignee: Kevin Klues > Labels: bootstrap, git > > The newly introduced way of finding the .git directory via --git-common-dir > is only supported on newer versions of git. Fallback to the older --git-dir > method if --git-common-dir is not supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3831) Document operator HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-3831:
--
Assignee: Kevin Klues (was: Benjamin Mahler)
> Document operator HTTP endpoints
>
>
> Key: MESOS-3831
> URL: https://issues.apache.org/jira/browse/MESOS-3831
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Neil Conway
>Assignee: Kevin Klues
>Priority: Minor
> Labels: documentation, mesosphere, newbie
>
> These are not exhaustively documented; they probably should be.
> Some endpoints have docs: e.g., {{/reserve}} and {{/unreserve}} are described
> in the reservation doc page. But it would be good to have a single page that
> lists all the endpoints and their semantics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2017:
---
Labels: mesosphere (was: twitter)
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: mesosphere, tests
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:1242] The newly elected leader is
> master@67.195.81.187:40429 with id 20141030-055506-3142697795-40429-24459
> I1030 05:55:06.943063 24474 master.cpp:1255] Elected as the leading master!
> I1030 05:55:06.943079 24474 master.cpp:1073] Recovering from registrar
> I1030 05:55:06.943313 24480 registrar.cpp:313] Recovering registrar
> I1030 05:55:06.943455 24475 recover.cpp:554] Updating replica status to VOTING
> I1030 05:55:06.944144 24474 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 536365ns
> I1030 05:55:06.944172 24474 replica.cpp:320] Persisted replica status to
> VOTING
> I1030 05:55:06.944355 24489 recover.cpp:568] Successfully joined the Paxos
> group
> I1030 05:55:06.944576 24489 recover.cpp:452] Recover process terminated
> I1030 05:55:06.945155 24486 log.cpp:656] Attempting to start the writer
> I1030 05:55:06.947013 24473 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1030 05:55:06.947854 24473 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 806463ns
> I1030 05:55:06.947883 24473 replica.cpp:342] Persisted promised to 1
> I1030 05:55:06.948547 24481 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1030 05:55:06.950269 24479 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1030 05:55:06.950933 24479 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 603843ns
> I1030 05:55:06.950961 24479 replica.cpp:676] Persisted action at 0
> I1030 05:55:06.952180 24476 replica.cpp:508] Replica received write request
> for position 0
> I1030 05:55:06.952239 24476 leveldb.cpp:438] Reading position from leveldb
> took 28437ns
> I1030 05:55:06.952896 244
[jira] [Updated] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2017:
---
Sprint: Twitter Mesos Q4 Sprint 3, Mesosphere Sprint 27 (was: Twitter
Mesos Q4 Sprint 3)
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: twitter
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:1242] The newly elected leader is
> master@67.195.81.187:40429 with id 20141030-055506-3142697795-40429-24459
> I1030 05:55:06.943063 24474 master.cpp:1255] Elected as the leading master!
> I1030 05:55:06.943079 24474 master.cpp:1073] Recovering from registrar
> I1030 05:55:06.943313 24480 registrar.cpp:313] Recovering registrar
> I1030 05:55:06.943455 24475 recover.cpp:554] Updating replica status to VOTING
> I1030 05:55:06.944144 24474 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 536365ns
> I1030 05:55:06.944172 24474 replica.cpp:320] Persisted replica status to
> VOTING
> I1030 05:55:06.944355 24489 recover.cpp:568] Successfully joined the Paxos
> group
> I1030 05:55:06.944576 24489 recover.cpp:452] Recover process terminated
> I1030 05:55:06.945155 24486 log.cpp:656] Attempting to start the writer
> I1030 05:55:06.947013 24473 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1030 05:55:06.947854 24473 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 806463ns
> I1030 05:55:06.947883 24473 replica.cpp:342] Persisted promised to 1
> I1030 05:55:06.948547 24481 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1030 05:55:06.950269 24479 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1030 05:55:06.950933 24479 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 603843ns
> I1030 05:55:06.950961 24479 replica.cpp:676] Persisted action at 0
> I1030 05:55:06.952180 24476 replica.cpp:508] Replica received write request
> for position 0
> I1030 05:55:06.952239 24476 leveldb.cpp:438] Reading position from level
[jira] [Assigned] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-2017:
--
Assignee: Kevin Klues (was: Yan Xu)
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: twitter
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:1242] The newly elected leader is
> master@67.195.81.187:40429 with id 20141030-055506-3142697795-40429-24459
> I1030 05:55:06.943063 24474 master.cpp:1255] Elected as the leading master!
> I1030 05:55:06.943079 24474 master.cpp:1073] Recovering from registrar
> I1030 05:55:06.943313 24480 registrar.cpp:313] Recovering registrar
> I1030 05:55:06.943455 24475 recover.cpp:554] Updating replica status to VOTING
> I1030 05:55:06.944144 24474 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 536365ns
> I1030 05:55:06.944172 24474 replica.cpp:320] Persisted replica status to
> VOTING
> I1030 05:55:06.944355 24489 recover.cpp:568] Successfully joined the Paxos
> group
> I1030 05:55:06.944576 24489 recover.cpp:452] Recover process terminated
> I1030 05:55:06.945155 24486 log.cpp:656] Attempting to start the writer
> I1030 05:55:06.947013 24473 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1030 05:55:06.947854 24473 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 806463ns
> I1030 05:55:06.947883 24473 replica.cpp:342] Persisted promised to 1
> I1030 05:55:06.948547 24481 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1030 05:55:06.950269 24479 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1030 05:55:06.950933 24479 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 603843ns
> I1030 05:55:06.950961 24479 replica.cpp:676] Persisted action at 0
> I1030 05:55:06.952180 24476 replica.cpp:508] Replica received write request
> for position 0
> I1030 05:55:06.952239 24476 leveldb.cpp:438] Reading position from leveldb
> took 28437ns
> I1030 05:55:06.952896 2447
[jira] [Updated] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2017:
---
Shepherd: Benjamin Mahler
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: mesosphere, tests
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:1242] The newly elected leader is
> master@67.195.81.187:40429 with id 20141030-055506-3142697795-40429-24459
> I1030 05:55:06.943063 24474 master.cpp:1255] Elected as the leading master!
> I1030 05:55:06.943079 24474 master.cpp:1073] Recovering from registrar
> I1030 05:55:06.943313 24480 registrar.cpp:313] Recovering registrar
> I1030 05:55:06.943455 24475 recover.cpp:554] Updating replica status to VOTING
> I1030 05:55:06.944144 24474 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 536365ns
> I1030 05:55:06.944172 24474 replica.cpp:320] Persisted replica status to
> VOTING
> I1030 05:55:06.944355 24489 recover.cpp:568] Successfully joined the Paxos
> group
> I1030 05:55:06.944576 24489 recover.cpp:452] Recover process terminated
> I1030 05:55:06.945155 24486 log.cpp:656] Attempting to start the writer
> I1030 05:55:06.947013 24473 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1030 05:55:06.947854 24473 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 806463ns
> I1030 05:55:06.947883 24473 replica.cpp:342] Persisted promised to 1
> I1030 05:55:06.948547 24481 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1030 05:55:06.950269 24479 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1030 05:55:06.950933 24479 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 603843ns
> I1030 05:55:06.950961 24479 replica.cpp:676] Persisted action at 0
> I1030 05:55:06.952180 24476 replica.cpp:508] Replica received write request
> for position 0
> I1030 05:55:06.952239 24476 leveldb.cpp:438] Reading position from leveldb
> took 28437ns
> I1030 05:55:06.952896 24476 leveld
[jira] [Updated] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2017:
---
Labels: mesosphere tests (was: mesosphere)
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: mesosphere, tests
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:1242] The newly elected leader is
> master@67.195.81.187:40429 with id 20141030-055506-3142697795-40429-24459
> I1030 05:55:06.943063 24474 master.cpp:1255] Elected as the leading master!
> I1030 05:55:06.943079 24474 master.cpp:1073] Recovering from registrar
> I1030 05:55:06.943313 24480 registrar.cpp:313] Recovering registrar
> I1030 05:55:06.943455 24475 recover.cpp:554] Updating replica status to VOTING
> I1030 05:55:06.944144 24474 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 536365ns
> I1030 05:55:06.944172 24474 replica.cpp:320] Persisted replica status to
> VOTING
> I1030 05:55:06.944355 24489 recover.cpp:568] Successfully joined the Paxos
> group
> I1030 05:55:06.944576 24489 recover.cpp:452] Recover process terminated
> I1030 05:55:06.945155 24486 log.cpp:656] Attempting to start the writer
> I1030 05:55:06.947013 24473 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1030 05:55:06.947854 24473 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 806463ns
> I1030 05:55:06.947883 24473 replica.cpp:342] Persisted promised to 1
> I1030 05:55:06.948547 24481 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1030 05:55:06.950269 24479 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1030 05:55:06.950933 24479 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 603843ns
> I1030 05:55:06.950961 24479 replica.cpp:676] Persisted action at 0
> I1030 05:55:06.952180 24476 replica.cpp:508] Replica received write request
> for position 0
> I1030 05:55:06.952239 24476 leveldb.cpp:438] Reading position from leveldb
> took 28437ns
> I1030 05:55:06.9
[jira] [Commented] (MESOS-4409) MasterTest.MaxCompletedFrameworksFlag is flaky
[
https://issues.apache.org/jira/browse/MESOS-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15102601#comment-15102601
]
Kevin Klues commented on MESOS-4409:
Yeah, this is the new unit test I just pushed through last night. It looks
like one of the frameworks I create fails to shutdown properly. Any insight as
to why this might happen? It never happened locally for me.
> MasterTest.MaxCompletedFrameworksFlag is flaky
> --
>
> Key: MESOS-4409
> URL: https://issues.apache.org/jira/browse/MESOS-4409
> Project: Mesos
> Issue Type: Bug
> Components: master, tests
>Affects Versions: 0.26.0
> Environment: On Jenkins CI: gcc,--verbose,ubuntu:14.04,docker
>Reporter: Greg Mann
> Labels: flaky-test, mesosphere, tests
>
> Saw this failure on Jenkins CI:
> {code}
> [ RUN ] MasterTest.MaxCompletedFrameworksFlag
> I0115 21:24:50.344116 31507 leveldb.cpp:174] Opened db in 2.062201ms
> I0115 21:24:50.344874 31507 leveldb.cpp:181] Compacted db in 716863ns
> I0115 21:24:50.344923 31507 leveldb.cpp:196] Created db iterator in 19087ns
> I0115 21:24:50.344949 31507 leveldb.cpp:202] Seeked to beginning of db in
> 1897ns
> I0115 21:24:50.344965 31507 leveldb.cpp:271] Iterated through 0 keys in the
> db in 298ns
> I0115 21:24:50.345012 31507 replica.cpp:779] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0115 21:24:50.345432 31536 recover.cpp:447] Starting replica recovery
> I0115 21:24:50.345657 31536 recover.cpp:473] Replica is in EMPTY status
> I0115 21:24:50.346535 31539 replica.cpp:673] Replica in EMPTY status received
> a broadcasted recover request from (6089)@172.17.0.4:52665
> I0115 21:24:50.347028 31540 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I0115 21:24:50.347554 31526 recover.cpp:564] Updating replica status to
> STARTING
> I0115 21:24:50.348175 31540 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 433937ns
> I0115 21:24:50.348215 31526 master.cpp:374] Master
> bf6ba047-245f-4e65-986c-1880cef81248 (4e6fbf10d387) started on
> 172.17.0.4:52665
> I0115 21:24:50.349417 31540 replica.cpp:320] Persisted replica status to
> STARTING
> I0115 21:24:50.349630 31536 recover.cpp:473] Replica is in STARTING status
> I0115 21:24:50.349421 31526 master.cpp:376] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/2wURTY/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="0"
> --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="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.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/2wURTY/master" --zk_session_timeout="10secs"
> I0115 21:24:50.349720 31526 master.cpp:421] Master only allowing
> authenticated frameworks to register
> I0115 21:24:50.349737 31526 master.cpp:426] Master only allowing
> authenticated slaves to register
> I0115 21:24:50.349750 31526 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/2wURTY/credentials'
> I0115 21:24:50.350005 31526 master.cpp:466] Using default 'crammd5'
> authenticator
> I0115 21:24:50.350132 31526 master.cpp:535] Using default 'basic' HTTP
> authenticator
> I0115 21:24:50.350256 31526 master.cpp:569] Authorization enabled
> I0115 21:24:50.350546 31529 hierarchical.cpp:147] Initialized hierarchical
> allocator process
> I0115 21:24:50.350626 31536 whitelist_watcher.cpp:77] No whitelist given
> I0115 21:24:50.350559 31538 replica.cpp:673] Replica in STARTING status
> received a broadcasted recover request from (6090)@172.17.0.4:52665
> I0115 21:24:50.351049 31534 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I0115 21:24:50.351704 31537 recover.cpp:564] Updating replica status to VOTING
> I0115 21:24:50.352221 31532 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 38ns
> I0115 21:24:50.352246 31532 replica.cpp:320] Persisted replica status to
> VOTING
> I0115 21:24:50.352371 31541 recover.cpp:578] Successfully joined the Paxos
> group
> I0115 21:24:50.352620 31541 recover.cpp:462] Recover process terminated
> I0115 21:24:50.3
[jira] [Updated] (MESOS-4185) Revisit the "System Requirements" for all systems in the "Getting Started" guide
[ https://issues.apache.org/jira/browse/MESOS-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4185: --- Assignee: (was: Kevin Klues) > Revisit the "System Requirements" for all systems in the "Getting Started" > guide > > > Key: MESOS-4185 > URL: https://issues.apache.org/jira/browse/MESOS-4185 > Project: Mesos > Issue Type: Documentation >Reporter: Kevin Klues >Priority: Minor > > The "System Requirements" section of our "Getting Started" guide needs an > overhaul. Much of the information is outdated, and could likely be distilled > down to a simpler set of dependencies (especially for Centos 6.6 and Centos > 7.1). We should take a good hard look at these and see if all of the > dependencies listed are necessary anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-4518) MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
[
https://issues.apache.org/jira/browse/MESOS-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-4518:
--
Assignee: Kevin Klues
> MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
> -
>
> Key: MESOS-4518
> URL: https://issues.apache.org/jira/browse/MESOS-4518
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Affects Versions: 0.26.0
> Environment: CentOS 7 with gcc
>Reporter: Greg Mann
>Assignee: Kevin Klues
> Labels: flaky-test, master, mesosphere
>
> Just observed this on ASF CI, CentOS 7 with gcc:
> {code}
> [ RUN ] MasterTest.MaxCompletedTasksPerFrameworkFlag
> I0126 21:09:41.845321 800 leveldb.cpp:174] Opened db in 2.419582ms
> I0126 21:09:41.846269 800 leveldb.cpp:181] Compacted db in 782855ns
> I0126 21:09:41.846392 800 leveldb.cpp:196] Created db iterator in 22135ns
> I0126 21:09:41.846416 800 leveldb.cpp:202] Seeked to beginning of db in
> 1956ns
> I0126 21:09:41.846431 800 leveldb.cpp:271] Iterated through 0 keys in the
> db in 388ns
> I0126 21:09:41.846479 800 replica.cpp:779] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0126 21:09:41.846972 824 recover.cpp:447] Starting replica recovery
> I0126 21:09:41.847550 824 recover.cpp:473] Replica is in EMPTY status
> I0126 21:09:41.849726 822 master.cpp:374] Master
> aed72a2b-829f-4ec9-b33a-5fac9421d44f (c0bf249b6465) started on
> 172.17.0.5:52680
> I0126 21:09:41.849967 822 master.cpp:376] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/a6rJ4B/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="0" --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.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/a6rJ4B/master" --zk_session_timeout="10secs"
> I0126 21:09:41.850344 822 master.cpp:421] Master only allowing
> authenticated frameworks to register
> I0126 21:09:41.850358 822 master.cpp:426] Master only allowing
> authenticated slaves to register
> I0126 21:09:41.850368 822 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/a6rJ4B/credentials'
> I0126 21:09:41.851260 822 master.cpp:466] Using default 'crammd5'
> authenticator
> I0126 21:09:41.851419 822 master.cpp:535] Using default 'basic' HTTP
> authenticator
> I0126 21:09:41.851541 822 master.cpp:569] Authorization enabled
> I0126 21:09:41.853004 832 whitelist_watcher.cpp:77] No whitelist given
> I0126 21:09:41.853294 820 hierarchical.cpp:144] Initialized hierarchical
> allocator process
> I0126 21:09:41.853672 822 master.cpp:1710] The newly elected leader is
> master@172.17.0.5:52680 with id aed72a2b-829f-4ec9-b33a-5fac9421d44f
> I0126 21:09:41.853703 822 master.cpp:1723] Elected as the leading master!
> I0126 21:09:41.853724 822 master.cpp:1468] Recovering from registrar
> I0126 21:09:41.853865 824 registrar.cpp:307] Recovering registrar
> I0126 21:09:41.854243 826 replica.cpp:673] Replica in EMPTY status received
> a broadcasted recover request from (6072)@172.17.0.5:52680
> I0126 21:09:41.854653 823 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I0126 21:09:41.855304 829 recover.cpp:564] Updating replica status to
> STARTING
> I0126 21:09:41.856170 828 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 727738ns
> I0126 21:09:41.856199 828 replica.cpp:320] Persisted replica status to
> STARTING
> I0126 21:09:41.856493 828 recover.cpp:473] Replica is in STARTING status
> I0126 21:09:41.857712 834 replica.cpp:673] Replica in STARTING status
> received a broadcasted recover request from (6073)@172.17.0.5:52680
> I0126 21:09:41.858253 830 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I0126 21:09:41.858752 830 recover.cpp:564] Updating replica status to VOTING
> I0126 21:09:41.860528 824 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 1.492538ms
> I0126 21:09:41.860620 824 replica.cpp:320] Persisted replica status to
> VOTING
> I0126 21:09:41.8
[jira] [Assigned] (MESOS-4525) MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
[
https://issues.apache.org/jira/browse/MESOS-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-4525:
--
Assignee: Kevin Klues
> MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
> -
>
> Key: MESOS-4525
> URL: https://issues.apache.org/jira/browse/MESOS-4525
> Project: Mesos
> Issue Type: Bug
> Components: master, tests
>Reporter: Neil Conway
>Assignee: Kevin Klues
> Labels: flaky-test, mesosphere
> Attachments: max_completed_tasks_test_verbose.txt
>
>
> Fails non-deterministically maybe 20% of the time on my Linux VM (recent
> ArchLinux, Linux 4.3.3, 8GB RAM and 4 CPU cores). Verbose test log attached.
> {noformat}
> GMOCK WARNING:
> Uninteresting mock function call - returning directly.
> Function call: resourceOffers(0x7ffccfe32470, @0x7f9f907b8960 { 144-byte
> object <20-9C EE-9D 9F-7F 00-00 00-00 00-00 00-00 00-00 40-7E 00-70 9F-7F
> 00-00 80-73 00-70 9F-7F 00-00 50-BF 05-70 9F-7F 00-00 F0-14 05-70 9F-7F 00-00
> D0-81 00-70 9F-7F 00-00 B0-04 05-70 9F-7F 00-00 ... 00-00 00-00 00-00 00-00
> 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00
> 00-00 00-00 00-00 00-00 00-00 9F-7F 00-00 00-00 00-00 00-00 00-00 00-00 00-00
> 1F-00 00-00> })
> Stack trace:
> /mesos-2/src/tests/master_tests.cpp:4031: Failure
> Failed to wait 15secs for offers
> I0127 14:31:37.140440 23181 master.cpp:1211] Framework
> 0c564384-9ae7-4b9a-821c-0254feff96e5- (default) at
> scheduler-90f8c513-e90f-43f0-a04c-8540a482bb12@10.0.2.15:46254 disconnected
> /mesos-2/src/tests/master_tests.cpp:4027: Failure
> Actual function call count doesn't match EXPECT_CALL(sched,
> resourceOffers(&schedDriver, _))...
> Expected: to be called at least once
>Actual: never called - unsatisfied and active
> /mesos-2/src/tests/master_tests.cpp:4008: Failure
> Actual function call count doesn't match EXPECT_CALL(exec, registered(_, _,
> _, _))...
> Expected: to be called once
>Actual: never called - unsatisfied and active
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4518) MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
[
https://issues.apache.org/jira/browse/MESOS-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4518:
---
Sprint: Mesosphere Sprint 27 (was: Mesosphere Sprint 28)
Review posted:
https://reviews.apache.org/r/42921/
> MasterTest.MaxCompletedTasksPerFrameworkFlag is flaky
> -
>
> Key: MESOS-4518
> URL: https://issues.apache.org/jira/browse/MESOS-4518
> Project: Mesos
> Issue Type: Bug
> Components: tests
>Affects Versions: 0.26.0
> Environment: CentOS 7 with gcc
>Reporter: Greg Mann
>Assignee: Kevin Klues
> Labels: flaky-test, master, mesosphere
>
> Just observed this on ASF CI, CentOS 7 with gcc:
> {code}
> [ RUN ] MasterTest.MaxCompletedTasksPerFrameworkFlag
> I0126 21:09:41.845321 800 leveldb.cpp:174] Opened db in 2.419582ms
> I0126 21:09:41.846269 800 leveldb.cpp:181] Compacted db in 782855ns
> I0126 21:09:41.846392 800 leveldb.cpp:196] Created db iterator in 22135ns
> I0126 21:09:41.846416 800 leveldb.cpp:202] Seeked to beginning of db in
> 1956ns
> I0126 21:09:41.846431 800 leveldb.cpp:271] Iterated through 0 keys in the
> db in 388ns
> I0126 21:09:41.846479 800 replica.cpp:779] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I0126 21:09:41.846972 824 recover.cpp:447] Starting replica recovery
> I0126 21:09:41.847550 824 recover.cpp:473] Replica is in EMPTY status
> I0126 21:09:41.849726 822 master.cpp:374] Master
> aed72a2b-829f-4ec9-b33a-5fac9421d44f (c0bf249b6465) started on
> 172.17.0.5:52680
> I0126 21:09:41.849967 822 master.cpp:376] Flags at startup: --acls=""
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="true" --authenticate_http="true" --authenticate_slaves="true"
> --authenticators="crammd5" --authorizers="local"
> --credentials="/tmp/a6rJ4B/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="0" --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.27.0/_inst/share/mesos/webui"
> --work_dir="/tmp/a6rJ4B/master" --zk_session_timeout="10secs"
> I0126 21:09:41.850344 822 master.cpp:421] Master only allowing
> authenticated frameworks to register
> I0126 21:09:41.850358 822 master.cpp:426] Master only allowing
> authenticated slaves to register
> I0126 21:09:41.850368 822 credentials.hpp:35] Loading credentials for
> authentication from '/tmp/a6rJ4B/credentials'
> I0126 21:09:41.851260 822 master.cpp:466] Using default 'crammd5'
> authenticator
> I0126 21:09:41.851419 822 master.cpp:535] Using default 'basic' HTTP
> authenticator
> I0126 21:09:41.851541 822 master.cpp:569] Authorization enabled
> I0126 21:09:41.853004 832 whitelist_watcher.cpp:77] No whitelist given
> I0126 21:09:41.853294 820 hierarchical.cpp:144] Initialized hierarchical
> allocator process
> I0126 21:09:41.853672 822 master.cpp:1710] The newly elected leader is
> master@172.17.0.5:52680 with id aed72a2b-829f-4ec9-b33a-5fac9421d44f
> I0126 21:09:41.853703 822 master.cpp:1723] Elected as the leading master!
> I0126 21:09:41.853724 822 master.cpp:1468] Recovering from registrar
> I0126 21:09:41.853865 824 registrar.cpp:307] Recovering registrar
> I0126 21:09:41.854243 826 replica.cpp:673] Replica in EMPTY status received
> a broadcasted recover request from (6072)@172.17.0.5:52680
> I0126 21:09:41.854653 823 recover.cpp:193] Received a recover response from
> a replica in EMPTY status
> I0126 21:09:41.855304 829 recover.cpp:564] Updating replica status to
> STARTING
> I0126 21:09:41.856170 828 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 727738ns
> I0126 21:09:41.856199 828 replica.cpp:320] Persisted replica status to
> STARTING
> I0126 21:09:41.856493 828 recover.cpp:473] Replica is in STARTING status
> I0126 21:09:41.857712 834 replica.cpp:673] Replica in STARTING status
> received a broadcasted recover request from (6073)@172.17.0.5:52680
> I0126 21:09:41.858253 830 recover.cpp:193] Received a recover response from
> a replica in STARTING status
> I0126 21:09:41.858752 830 recover.cpp:564] Updating replica status to VOTING
> I0126 21:09:41.860528 824 leveldb.cpp:304] Persisting metadata (8 bytes) to
> leveldb took 1.492538ms
> I0126 21:09:41.86062
[jira] [Created] (MESOS-4551) process::collect() and process::await only take a fixed number of arguments (when not using a list).
Kevin Klues created MESOS-4551: -- Summary: process::collect() and process::await only take a fixed number of arguments (when not using a list). Key: MESOS-4551 URL: https://issues.apache.org/jira/browse/MESOS-4551 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor The templated collect() and await() functions only allow either a single list argument or a fixed number of arguments to be passed to them. The fixed argument variant should be removed in favor of a variadic template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4551) process::collect() and process::await only take a fixed number of arguments (when not using a list).
[ https://issues.apache.org/jira/browse/MESOS-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123301#comment-15123301 ] Kevin Klues commented on MESOS-4551: https://reviews.apache.org/r/42955/ https://reviews.apache.org/r/42956/ > process::collect() and process::await only take a fixed number of arguments > (when not using a list). > > > Key: MESOS-4551 > URL: https://issues.apache.org/jira/browse/MESOS-4551 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > > The templated collect() and await() functions only allow either a single list > argument or a fixed number of arguments to be passed to them. The fixed > argument variant should be removed in favor of a variadic template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4552) There is currently no way to get at the strings in the global process::help object programmatically.
Kevin Klues created MESOS-4552: -- Summary: There is currently no way to get at the strings in the global process::help object programmatically. Key: MESOS-4552 URL: https://issues.apache.org/jira/browse/MESOS-4552 Project: Mesos Issue Type: Improvement Reporter: Kevin Klues Assignee: Kevin Klues Priority: Minor There is currently no way to extract the help strings from the help process once they have been installed into it. The only way to get at them is to visit the http endpoint they are associated with and pull it from there. Moreover, there is no way to uninstall a string from this process if a route is ever taken offline. We need support for programmatically getting/removing strings from the help process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4552) There is currently no way to get at the strings in the global process::help object programmatically.
[ https://issues.apache.org/jira/browse/MESOS-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123310#comment-15123310 ] Kevin Klues edited comment on MESOS-4552 at 1/29/16 10:23 AM: -- https://reviews.apache.org/r/42786/ https://reviews.apache.org/r/42957/ https://reviews.apache.org/r/42958/ was (Author: klueska): https://reviews.apache.org/r/42786/ https://reviews.apache.org/r/42957/ > There is currently no way to get at the strings in the global process::help > object programmatically. > > > Key: MESOS-4552 > URL: https://issues.apache.org/jira/browse/MESOS-4552 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > > There is currently no way to extract the help strings from the help process > once they have been installed into it. The only way to get at them is to > visit the http endpoint they are associated with and pull it from there. > Moreover, there is no way to uninstall a string from this process if a route > is ever taken offline. We need support for programmatically getting/removing > strings from the help process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3831) Document operator HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-3831:
---
Story Points: 3
> Document operator HTTP endpoints
>
>
> Key: MESOS-3831
> URL: https://issues.apache.org/jira/browse/MESOS-3831
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Neil Conway
>Assignee: Kevin Klues
>Priority: Minor
> Labels: documentation, mesosphere, newbie
>
> These are not exhaustively documented; they probably should be.
> Some endpoints have docs: e.g., {{/reserve}} and {{/unreserve}} are described
> in the reservation doc page. But it would be good to have a single page that
> lists all the endpoints and their semantics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4552) Help strings are not removed from the global help process upon process termination.
[ https://issues.apache.org/jira/browse/MESOS-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4552: --- Description: There is no way to uninstall a string from this process if a route is ever taken offline. We need support for programmatically removing strings from the help process and removing them upon process termination. (was: There is currently no way to extract the help strings from the help process once they have been installed into it. The only way to get at them is to visit the http endpoint they are associated with and pull it from there. Moreover, there is no way to uninstall a string from this process if a route is ever taken offline. We need support for programmatically getting/removing strings from the help process.) > Help strings are not removed from the global help process upon process > termination. > --- > > Key: MESOS-4552 > URL: https://issues.apache.org/jira/browse/MESOS-4552 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: mesosphere > > There is no way to uninstall a string from this process if a route is ever > taken offline. We need support for programmatically removing strings from > the help process and removing them upon process termination. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4552) Help strings are not removed from the global help process upon process termination.
[ https://issues.apache.org/jira/browse/MESOS-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Klues updated MESOS-4552: --- Summary: Help strings are not removed from the global help process upon process termination. (was: There is currently no way to get at the strings in the global process::help object programmatically.) > Help strings are not removed from the global help process upon process > termination. > --- > > Key: MESOS-4552 > URL: https://issues.apache.org/jira/browse/MESOS-4552 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: mesosphere > > There is currently no way to extract the help strings from the help process > once they have been installed into it. The only way to get at them is to > visit the http endpoint they are associated with and pull it from there. > Moreover, there is no way to uninstall a string from this process if a route > is ever taken offline. We need support for programmatically getting/removing > strings from the help process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4552) Help strings are not removed from the global help process upon process termination.
[ https://issues.apache.org/jira/browse/MESOS-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132989#comment-15132989 ] Kevin Klues commented on MESOS-4552: New set of reviews: https://reviews.apache.org/r/43218 https://reviews.apache.org/r/43219 https://reviews.apache.org/r/43215 https://reviews.apache.org/r/42957 > Help strings are not removed from the global help process upon process > termination. > --- > > Key: MESOS-4552 > URL: https://issues.apache.org/jira/browse/MESOS-4552 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Klues >Assignee: Kevin Klues >Priority: Minor > Labels: mesosphere > > There is no way to uninstall a string from this process if a route is ever > taken offline. We need support for programmatically removing strings from > the help process and removing them upon process termination. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4603) GTEST crashes when starting/stopping many times in succession
Kevin Klues created MESOS-4603:
--
Summary: GTEST crashes when starting/stopping many times in
succession
Key: MESOS-4603
URL: https://issues.apache.org/jira/browse/MESOS-4603
Project: Mesos
Issue Type: Bug
Components: tests
Environment: clang 3.4, ubuntu 14.04
Reporter: Kevin Klues
After running:
run-one-until-failure 3rdparty/libprocess/libprocess-tests
At least one iteration of running the tests fails in under a minute with the
following stack trace. The stack trace is differnt sometimes, but it always
seems to error out in ~ProcessManager().
{noformat}
*** Aborted at 1454643530 (unix time) try "date -d @1454643530" if you are
using GNU date ***
PC: @ 0x7f7812f4d1a0 (unknown)
*** SIGSEGV (@0x0) received by PID 168122 (TID 0x7f780298f700) from PID 0;
stack trace: ***
@ 0x7f7814451340 (unknown)
@ 0x7f7812f4d1a0 (unknown)
@ 0x5f06a0 process::Process<>::self()
@ 0x777220
_ZN7process8dispatchI7NothingNS_20AsyncExecutorProcessERKZZNS_4http8internal7requestERKNS3_7RequestEbENK3$_1clENS3_10ConnectionEEUlvE_PvSA_SD_EENS_6FutureIT_EEPKNS_7ProcessIT0_EEMSI_FSF_T1_T2_ET3_T4_
@ 0x77714c
_ZN7process13AsyncExecutor7executeIZZNS_4http8internal7requestERKNS2_7RequestEbENK3$_1clENS2_10ConnectionEEUlvE_EENS_6FutureI7NothingEERKT_PN5boost9enable_ifINSG_7is_voidINSt9result_ofIFSD_vEE4typeEEEvE4typeE
@ 0x77709e
_ZN7process5asyncIZZNS_4http8internal7requestERKNS1_7RequestEbENK3$_1clENS1_10ConnectionEEUlvE_EENS_6FutureI7NothingEERKT_PN5boost9enable_ifINSF_7is_voidINSt9result_ofIFSC_vEE4typeEEEvE4typeE
@ 0x777046
_ZZZN7process4http8internal7requestERKNS0_7RequestEbENK3$_1clENS0_10ConnectionEENKUlvE0_clEv
@ 0x777019
_ZZNK7process6FutureI7NothingE5onAnyIZZNS_4http8internal7requestERKNS4_7RequestEbENK3$_1clENS4_10ConnectionEEUlvE0_vEERKS2_OT_NS2_10LessPreferEENUlSD_E_clESD_
@ 0x776e02
_ZNSt17_Function_handlerIFvRKN7process6FutureI7NothingEEEZNKS3_5onAnyIZZNS0_4http8internal7requestERKNS8_7RequestEbENK3$_1clENS8_10ConnectionEEUlvE0_vEES5_OT_NS3_10LessPreferEEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_
@ 0x43f888 std::function<>::operator()()
@ 0x4464ec
_ZN7process8internal3runISt8functionIFvRKNS_6FutureI7NothingJRS5_EEEvRKSt6vectorIT_SaISC_EEDpOT0_
@ 0x446305 process::Future<>::set()
@ 0x44f90a
_ZNKSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS2_EEclIJS5_EvEEbRS3_DpOT_
@ 0x44f7ae
_ZNSt5_BindIFSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS3_EES4_St12_PlaceholderILi16__callIbJS6_EJLm0ELm1T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
@ 0x44f72d
_ZNSt5_BindIFSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS3_EES4_St12_PlaceholderILi1clIJS6_EbEET0_DpOT_
@ 0x44f6dd
_ZZNK7process6FutureI7NothingE7onReadyISt5_BindIFSt7_Mem_fnIMS2_FbRKS1_EES2_St12_PlaceholderILi1bEERKS2_OT_NS2_6PreferEENUlS7_E_clES7_
@ 0x44f492
_ZNSt17_Function_handlerIFvRK7NothingEZNK7process6FutureIS0_E7onReadyISt5_BindIFSt7_Mem_fnIMS6_FbS2_EES6_St12_PlaceholderILi1bEERKS6_OT_NS6_6PreferEEUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
@ 0x446d68 std::function<>::operator()()
@ 0x44644c
_ZN7process8internal3runISt8functionIFvRK7NothingEEJRS3_EEEvRKSt6vectorIT_SaISA_EEDpOT0_
@ 0x4462e7 process::Future<>::set()
@ 0x50d5c7 process::Promise<>::set()
@ 0x77c53b
process::http::internal::ConnectionProcess::disconnect()
@ 0x792710 process::http::internal::ConnectionProcess::_read()
@ 0x794356
_ZZN7process8dispatchINS_4http8internal17ConnectionProcessERKNS_6FutureISsEES5_EEvRKNS_3PIDIT_EEMS9_FvT0_ET1_ENKUlPNS_11ProcessBaseEE_clESI_
@ 0x793fa2
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchINS0_4http8internal17ConnectionProcessERKNS0_6FutureISsEES9_EEvRKNS0_3PIDIT_EEMSD_FvT0_ET1_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
@ 0x810958 std::function<>::operator()()
@ 0x7fb854 process::ProcessBase::visit()
@ 0x8581ce process::DispatchEvent::visit()
@ 0x43d631 process::ProcessBase::serve()
@ 0x7f9604 process::ProcessManager::resume()
@ 0x8017a5
process::ProcessManager::init_threads()::$_1::operator()()
@ 0x8016e3
_ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvE3$_1St17reference_wrapperIKSt11atomic_boolEEE6__callIvJEJLm0T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3307) Configurable size of completed task / framework history
[
https://issues.apache.org/jira/browse/MESOS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134538#comment-15134538
]
Kevin Klues commented on MESOS-3307:
I'm all for query parameters to filter this stuff, but others seem to disagree.
(See the thread above).
> Configurable size of completed task / framework history
> ---
>
> Key: MESOS-3307
> URL: https://issues.apache.org/jira/browse/MESOS-3307
> Project: Mesos
> Issue Type: Bug
>Reporter: Ian Babrou
>Assignee: Kevin Klues
> Labels: mesosphere
> Fix For: 0.27.0
>
>
> We try to make Mesos work with multiple frameworks and mesos-dns at the same
> time. The goal is to have set of frameworks per team / project on a single
> Mesos cluster.
> At this point our mesos state.json is at 4mb and it takes a while to
> assembly. 5 mesos-dns instances hit state.json every 5 seconds, effectively
> pushing mesos-master CPU usage through the roof. It's at 100%+ all the time.
> Here's the problem:
> {noformat}
> mesos λ curl -s http://mesos-master:5050/master/state.json | jq
> .frameworks[].completed_tasks[].framework_id | sort | uniq -c | sort -n
>1 "20150606-001827-252388362-5050-5982-0003"
> 16 "20150606-001827-252388362-5050-5982-0005"
> 18 "20150606-001827-252388362-5050-5982-0029"
> 73 "20150606-001827-252388362-5050-5982-0007"
> 141 "20150606-001827-252388362-5050-5982-0009"
> 154 "20150820-154817-302720010-5050-15320-"
> 289 "20150606-001827-252388362-5050-5982-0004"
> 510 "20150606-001827-252388362-5050-5982-0012"
> 666 "20150606-001827-252388362-5050-5982-0028"
> 923 "20150116-002612-269165578-5050-32204-0003"
> 1000 "20150606-001827-252388362-5050-5982-0001"
> 1000 "20150606-001827-252388362-5050-5982-0006"
> 1000 "20150606-001827-252388362-5050-5982-0010"
> 1000 "20150606-001827-252388362-5050-5982-0011"
> 1000 "20150606-001827-252388362-5050-5982-0027"
> mesos λ fgrep 1000 -r src/master
> src/master/constants.cpp:const size_t MAX_REMOVED_SLAVES = 10;
> src/master/constants.cpp:const uint32_t MAX_COMPLETED_TASKS_PER_FRAMEWORK =
> 1000;
> {noformat}
> Active tasks are just 6% of state.json response:
> {noformat}
> mesos λ cat ~/temp/mesos-state.json | jq -c . | wc
>1 14796 4138942
> mesos λ cat ~/temp/mesos-state.json | jq .frameworks[].tasks | jq -c . | wc
> 16 37 252774
> {noformat}
> I see four options that can improve the situation:
> 1. Add query string param to exclude completed tasks from state.json and use
> it in mesos-dns and similar tools. There is no need for mesos-dns to know
> about completed tasks, it's just extra load on master and mesos-dns.
> 2. Make history size configurable.
> 3. Make JSON serialization faster. With 1s of tasks even without history
> it would take a lot of time to serialize tasks for mesos-dns. Doing it every
> 60 seconds instead of every 5 seconds isn't really an option.
> 4. Create event bus for mesos master. Marathon has it and it'd be nice to
> have it in Mesos. This way mesos-dns could avoid polling master state and
> switch to listening for events.
> All can be done independently.
> Note to mesosphere folks: please start distributing debug symbols with your
> distribution. I was asking for it for a while and it is really helpful:
> https://github.com/mesosphere/marathon/issues/1497#issuecomment-104182501
> Perf report for leading master:
> !http://i.imgur.com/iz7C3o0.png!
> I'm on 0.23.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
Kevin Klues created MESOS-4611:
--
Summary: Passing a lambda to dispatch() always matches the
template returning void
Key: MESOS-4611
URL: https://issues.apache.org/jira/browse/MESOS-4611
Project: Mesos
Issue Type: Bug
Components: libprocess
Reporter: Kevin Klues
The following idiom does not currently compile:
{code}
Future initialized = dispatch(pid, [] () -> Nothing {
return Nothing();
})
{code}
This seems non-intuitive because the following template exists for dispatch:
{code}
template
Future dispatch(const UPID& pid, const std::function& f)
{
std::shared_ptr> promise(new Promise());
std::shared_ptr> f_(
new std::function(
[=](ProcessBase*) {
promise->set(f());
}));
internal::dispatch(pid, f_);
return promise->future();
}
{code}
To make this work, you have to explicitly type the lambda before passing it to
dispatch.
{code}
std::function f = []() { return Nothing(); };
Future initialized = dispatch(pid, f);
{code}
We should add template support to allow lambdas to be passed to dispatch()
without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4611:
---
Description:
The following idiom does not currently compile:
{code}
Future initialized = dispatch(pid, [] () -> Nothing {
return Nothing();
});
{code}
This seems non-intuitive because the following template exists for dispatch:
{code}
template
Future dispatch(const UPID& pid, const std::function& f)
{
std::shared_ptr> promise(new Promise());
std::shared_ptr> f_(
new std::function(
[=](ProcessBase*) {
promise->set(f());
}));
internal::dispatch(pid, f_);
return promise->future();
}
{code}
However, lambdas cannot be implicitly cast to a corresponding
std::function type.
To make this work, you have to explicitly type the lambda before passing it to
dispatch.
{code}
std::function f = []() { return Nothing(); };
Future initialized = dispatch(pid, f);
{code}
We should add template support to allow lambdas to be passed to dispatch()
without explicit typing.
was:
The following idiom does not currently compile:
{code}
Future initialized = dispatch(pid, [] () -> Nothing {
return Nothing();
})
{code}
This seems non-intuitive because the following template exists for dispatch:
{code}
template
Future dispatch(const UPID& pid, const std::function& f)
{
std::shared_ptr> promise(new Promise());
std::shared_ptr> f_(
new std::function(
[=](ProcessBase*) {
promise->set(f());
}));
internal::dispatch(pid, f_);
return promise->future();
}
{code}
To make this work, you have to explicitly type the lambda before passing it to
dispatch.
{code}
std::function f = []() { return Nothing(); };
Future initialized = dispatch(pid, f);
{code}
We should add template support to allow lambdas to be passed to dispatch()
without explicit typing.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr> promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4603) GTEST crashes when starting/stopping many times in succession
[
https://issues.apache.org/jira/browse/MESOS-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-4603:
---
Labels: mesosphere tests (was: tests)
> GTEST crashes when starting/stopping many times in succession
> -
>
> Key: MESOS-4603
> URL: https://issues.apache.org/jira/browse/MESOS-4603
> Project: Mesos
> Issue Type: Bug
> Components: tests
> Environment: clang 3.4, ubuntu 14.04
>Reporter: Kevin Klues
> Labels: mesosphere, tests
>
> After running:
> run-one-until-failure 3rdparty/libprocess/libprocess-tests
> At least one iteration of running the tests fails in under a minute with the
> following stack trace. The stack trace is differnt sometimes, but it always
> seems to error out in ~ProcessManager().
> {noformat}
> *** Aborted at 1454643530 (unix time) try "date -d @1454643530" if you are
> using GNU date ***
> PC: @ 0x7f7812f4d1a0 (unknown)
> *** SIGSEGV (@0x0) received by PID 168122 (TID 0x7f780298f700) from PID 0;
> stack trace: ***
> @ 0x7f7814451340 (unknown)
> @ 0x7f7812f4d1a0 (unknown)
> @ 0x5f06a0 process::Process<>::self()
> @ 0x777220
> _ZN7process8dispatchI7NothingNS_20AsyncExecutorProcessERKZZNS_4http8internal7requestERKNS3_7RequestEbENK3$_1clENS3_10ConnectionEEUlvE_PvSA_SD_EENS_6FutureIT_EEPKNS_7ProcessIT0_EEMSI_FSF_T1_T2_ET3_T4_
> @ 0x77714c
> _ZN7process13AsyncExecutor7executeIZZNS_4http8internal7requestERKNS2_7RequestEbENK3$_1clENS2_10ConnectionEEUlvE_EENS_6FutureI7NothingEERKT_PN5boost9enable_ifINSG_7is_voidINSt9result_ofIFSD_vEE4typeEEEvE4typeE
> @ 0x77709e
> _ZN7process5asyncIZZNS_4http8internal7requestERKNS1_7RequestEbENK3$_1clENS1_10ConnectionEEUlvE_EENS_6FutureI7NothingEERKT_PN5boost9enable_ifINSF_7is_voidINSt9result_ofIFSC_vEE4typeEEEvE4typeE
> @ 0x777046
> _ZZZN7process4http8internal7requestERKNS0_7RequestEbENK3$_1clENS0_10ConnectionEENKUlvE0_clEv
> @ 0x777019
> _ZZNK7process6FutureI7NothingE5onAnyIZZNS_4http8internal7requestERKNS4_7RequestEbENK3$_1clENS4_10ConnectionEEUlvE0_vEERKS2_OT_NS2_10LessPreferEENUlSD_E_clESD_
> @ 0x776e02
> _ZNSt17_Function_handlerIFvRKN7process6FutureI7NothingEEEZNKS3_5onAnyIZZNS0_4http8internal7requestERKNS8_7RequestEbENK3$_1clENS8_10ConnectionEEUlvE0_vEES5_OT_NS3_10LessPreferEEUlS5_E_E9_M_invokeERKSt9_Any_dataS5_
> @ 0x43f888 std::function<>::operator()()
> @ 0x4464ec
> _ZN7process8internal3runISt8functionIFvRKNS_6FutureI7NothingJRS5_EEEvRKSt6vectorIT_SaISC_EEDpOT0_
> @ 0x446305 process::Future<>::set()
> @ 0x44f90a
> _ZNKSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS2_EEclIJS5_EvEEbRS3_DpOT_
> @ 0x44f7ae
> _ZNSt5_BindIFSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS3_EES4_St12_PlaceholderILi16__callIbJS6_EJLm0ELm1T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
> @ 0x44f72d
> _ZNSt5_BindIFSt7_Mem_fnIMN7process6FutureI7NothingEEFbRKS3_EES4_St12_PlaceholderILi1clIJS6_EbEET0_DpOT_
> @ 0x44f6dd
> _ZZNK7process6FutureI7NothingE7onReadyISt5_BindIFSt7_Mem_fnIMS2_FbRKS1_EES2_St12_PlaceholderILi1bEERKS2_OT_NS2_6PreferEENUlS7_E_clES7_
> @ 0x44f492
> _ZNSt17_Function_handlerIFvRK7NothingEZNK7process6FutureIS0_E7onReadyISt5_BindIFSt7_Mem_fnIMS6_FbS2_EES6_St12_PlaceholderILi1bEERKS6_OT_NS6_6PreferEEUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x446d68 std::function<>::operator()()
> @ 0x44644c
> _ZN7process8internal3runISt8functionIFvRK7NothingEEJRS3_EEEvRKSt6vectorIT_SaISA_EEDpOT0_
> @ 0x4462e7 process::Future<>::set()
> @ 0x50d5c7 process::Promise<>::set()
> @ 0x77c53b
> process::http::internal::ConnectionProcess::disconnect()
> @ 0x792710 process::http::internal::ConnectionProcess::_read()
> @ 0x794356
> _ZZN7process8dispatchINS_4http8internal17ConnectionProcessERKNS_6FutureISsEES5_EEvRKNS_3PIDIT_EEMS9_FvT0_ET1_ENKUlPNS_11ProcessBaseEE_clESI_
> @ 0x793fa2
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchINS0_4http8internal17ConnectionProcessERKNS0_6FutureISsEES9_EEvRKNS0_3PIDIT_EEMSD_FvT0_ET1_EUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
> @ 0x810958 std::function<>::operator()()
> @ 0x7fb854 process::ProcessBase::visit()
> @ 0x8581ce process::DispatchEvent::visit()
> @ 0x43d631 process::ProcessBase::serve()
> @ 0x7f9604 process::ProcessManager::resume()
> @ 0x8017a5
> process::ProcessManager::init_threads()::$_1::operator()()
> @ 0x8016e3
> _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvE3$_1St17reference_wrapperIKSt11atomic_boolE
[jira] [Commented] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136387#comment-15136387
]
Kevin Klues commented on MESOS-4611:
No, that has the same problem.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr> promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-4611) Passing a lambda to dispatch() always matches the template returning void
[
https://issues.apache.org/jira/browse/MESOS-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136387#comment-15136387
]
Kevin Klues edited comment on MESOS-4611 at 2/7/16 7:26 PM:
No, that has the same problem. [~mpark] summarized for me offline why our
current templates can't match this. The basic problem is that lambda's cant be
implicitly cast to the std::function() type, so we end up matching with a
different dispatch() template which returns a void.
was (Author: klueska):
No, that has the same problem.
> Passing a lambda to dispatch() always matches the template returning void
> -
>
> Key: MESOS-4611
> URL: https://issues.apache.org/jira/browse/MESOS-4611
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
>Reporter: Kevin Klues
> Labels: dispatch, libprocess, mesosphere
>
> The following idiom does not currently compile:
> {code}
> Future initialized = dispatch(pid, [] () -> Nothing {
> return Nothing();
> });
> {code}
> This seems non-intuitive because the following template exists for dispatch:
> {code}
> template
> Future dispatch(const UPID& pid, const std::function& f)
> {
> std::shared_ptr> promise(new Promise());
>
> std::shared_ptr> f_(
> new std::function(
> [=](ProcessBase*) {
> promise->set(f());
> }));
> internal::dispatch(pid, f_);
>
> return promise->future();
> }
> {code}
> However, lambdas cannot be implicitly cast to a corresponding
> std::function type.
> To make this work, you have to explicitly type the lambda before passing it
> to dispatch.
> {code}
> std::function f = []() { return Nothing(); };
> Future initialized = dispatch(pid, f);
> {code}
> We should add template support to allow lambdas to be passed to dispatch()
> without explicit typing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2007) AllocatorTest/0.SlaveReregistersFirst is flaky
[
https://issues.apache.org/jira/browse/MESOS-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-2007:
--
Assignee: Kevin Klues
> AllocatorTest/0.SlaveReregistersFirst is flaky
> --
>
> Key: MESOS-2007
> URL: https://issues.apache.org/jira/browse/MESOS-2007
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
> Environment: https://builds.apache.org/computer/ubuntu-1/systemInfo
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: flaky
>
> {noformat:title=}
> [ RUN ] AllocatorTest/0.SlaveReregistersFirst
> Using temporary directory '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d'
> I1028 23:48:22.360447 31190 leveldb.cpp:176] Opened db in 2.192575ms
> I1028 23:48:22.361253 31190 leveldb.cpp:183] Compacted db in 760753ns
> I1028 23:48:22.361320 31190 leveldb.cpp:198] Created db iterator in 22188ns
> I1028 23:48:22.361340 31190 leveldb.cpp:204] Seeked to beginning of db in
> 1950ns
> I1028 23:48:22.361351 31190 leveldb.cpp:273] Iterated through 0 keys in the
> db in 345ns
> I1028 23:48:22.361403 31190 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1028 23:48:22.362185 31217 recover.cpp:437] Starting replica recovery
> I1028 23:48:22.362764 31219 recover.cpp:463] Replica is in EMPTY status
> I1028 23:48:22.363955 31210 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1028 23:48:22.364320 31217 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1028 23:48:22.364820 31211 recover.cpp:554] Updating replica status to
> STARTING
> I1028 23:48:22.365365 31215 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 418991ns
> I1028 23:48:22.365391 31215 replica.cpp:320] Persisted replica status to
> STARTING
> I1028 23:48:22.365617 31217 recover.cpp:463] Replica is in STARTING status
> I1028 23:48:22.366328 31206 master.cpp:312] Master
> 20141028-234822-3193029443-50043-31190 (pietas.apache.org) started on
> 67.195.81.190:50043
> I1028 23:48:22.366377 31206 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1028 23:48:22.366391 31206 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1028 23:48:22.366402 31206 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d/credentials'
> I1028 23:48:22.366708 31206 master.cpp:392] Authorization enabled
> I1028 23:48:22.366886 31209 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1028 23:48:22.367311 31208 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1028 23:48:22.367312 31207 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1028 23:48:22.367686 31211 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.190:50043
> I1028 23:48:22.367863 31212 recover.cpp:554] Updating replica status to VOTING
> I1028 23:48:22.368477 31218 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 375527ns
> I1028 23:48:22.368505 31218 replica.cpp:320] Persisted replica status to
> VOTING
> I1028 23:48:22.368517 31204 master.cpp:1242] The newly elected leader is
> master@67.195.81.190:50043 with id 20141028-234822-3193029443-50043-31190
> I1028 23:48:22.368549 31204 master.cpp:1255] Elected as the leading master!
> I1028 23:48:22.368567 31204 master.cpp:1073] Recovering from registrar
> I1028 23:48:22.368621 31215 recover.cpp:568] Successfully joined the Paxos
> group
> I1028 23:48:22.368716 31219 registrar.cpp:313] Recovering registrar
> I1028 23:48:22.369000 31215 recover.cpp:452] Recover process terminated
> I1028 23:48:22.369523 31208 log.cpp:656] Attempting to start the writer
> I1028 23:48:22.370909 31205 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1028 23:48:22.371266 31205 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 325016ns
> I1028 23:48:22.371290 31205 replica.cpp:342] Persisted promised to 1
> I1028 23:48:22.371979 31218 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1028 23:48:22.373378 31210 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1028 23:48:22.373746 31210 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 329018ns
> I1028 23:48:22.373772 31210 replica.cpp:676] Persisted action at 0
> I1028 23:48:22.374897 31214 replica.cpp:508] Replica received write request
> for position 0
> I1028 23:48:22.374951 31214 leveldb.cpp:438] Reading position from leveldb
> took 26002ns
> I1028 23:48:22.375272 31214 leveldb.cpp:343] Pe
[jira] [Commented] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139458#comment-15139458
]
Kevin Klues commented on MESOS-2017:
I am marking this ticket as closed for the following reasons. If you feel this
is in error, please reopen it with specific details and a way to reproduce the
bug. Thanks!
1) Unfortunately, we don't have archives of the Jenkins builds before April
2015, so I don't have any easy way of seeing the exact last time this error
occurred. However, we do know it has not cropped up on the Jenkins builds
since at least December 2015:
http://www.mail-archive.com/search?q=pure+virtual&l=builds%40mesos.apache.org
2) As suggested above, I reset my Mesos tree to:
{noformat}
commit 5d5b65e5722a21868315d80eb05428b11b4d87d0
Author: Adam B
Date: Mon Oct 13 21:33:11 2014 -0700
Enabled whitespace/semicolon rule for cpplint.
{noformat}
and ran the following command, trying to trigger the "RAW: Pure virtual method
called" error for the two test mentioned in this thread as well as the test
mentioned in the related issue (MESOS-2007).
GTEST_FILTER="DRFAllocatorTest.DRFAllocatorProcess:ReconciliationTest.TaskStateMismatch:AllocatorTest/0.SlaveReregistersFirst"
run-one-until-failure src/mesos-tests --verbose
I ran this test continuously overnight on 2 different setups without error:
-- My native Mac OS X setup
-- A docker container based on the support/docker_build.sh script in newer
Mesoses.
I set up the docker with the following configuration:
COMPILER=clang, CONFIGURATION=--verbose, ENVIRONMENT=GLOG_v=1, MESOS_VERBOSE=1,
OS=ubuntu:14.04, label_exp=docker||Hadoop/1638/changes
3) Recently a new ticket with a similar error has cropped up (MESOS-4604), but
we have diagnosed this problem already and it is unrelated to the errors seen
in this test (details are in the ticket itself).
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: mesosphere, tests
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replica recovery
> I1030 05:55:06.937023 24480 recover.cpp:463] Replica is in EMPTY status
> I1030 05:55:06.938158 24475 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1030 05:55:06.938859 24482 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1030 05:55:06.939486 24474 recover.cpp:554] Updating replica status to
> STARTING
> I1030 05:55:06.940249 24489 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 591981ns
> I1030 05:55:06.940274 24489 replica.cpp:320] Persisted replica status to
> STARTING
> I1030 05:55:06.940752 24481 recover.cpp:463] Replica is in STARTING status
> I1030 05:55:06.940820 24489 master.cpp:312] Master
> 20141030-055506-3142697795-40429-24459 (pomona.apache.org) started on
> 67.195.81.187:40429
> I1030 05:55:06.940871 24489 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1030 05:55:06.940891 24489 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1030 05:55:06.940908 24489 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j/credentials'
> I1030 05:55:06.941215 24489 master.cpp:392] Authorization enabled
> I1030 05:55:06.941751 24475 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1030 05:55:06.942227 24474 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1030 05:55:06.942401 24476 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.187:40429
> I1030 05:55:06.942895 24483 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1030 05:55:06.943035 24474 master.cpp:124
[jira] [Comment Edited] (MESOS-2017) Segfault with "Pure virtual method called" when tests fail
[
https://issues.apache.org/jira/browse/MESOS-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139458#comment-15139458
]
Kevin Klues edited comment on MESOS-2017 at 2/9/16 7:19 PM:
I propose to mark this ticket as closed for the following reasons. If you feel
this is in error, please reopen it with specific details and a way to reproduce
the bug. Thanks!
1) Unfortunately, we don't have archives of the Jenkins builds before April
2015, so I don't have any easy way of seeing the exact last time this error
occurred. However, we do know it has not cropped up on the Jenkins builds
since at least December 2015:
http://www.mail-archive.com/search?q=pure+virtual&l=builds%40mesos.apache.org
2) As suggested above, I reset my Mesos tree to:
{noformat}
commit 5d5b65e5722a21868315d80eb05428b11b4d87d0
Author: Adam B
Date: Mon Oct 13 21:33:11 2014 -0700
Enabled whitespace/semicolon rule for cpplint.
{noformat}
and ran the following command, trying to trigger the "RAW: Pure virtual method
called" error for the two test mentioned in this thread as well as the test
mentioned in the related issue (MESOS-2007).
GTEST_FILTER="DRFAllocatorTest.DRFAllocatorProcess:ReconciliationTest.TaskStateMismatch:AllocatorTest/0.SlaveReregistersFirst"
run-one-until-failure src/mesos-tests --verbose
I ran this test continuously overnight on 2 different setups without error:
-- My native Mac OS X setup
-- A docker container based on the support/docker_build.sh script in newer
Mesoses.
I set up the docker with the following configuration:
COMPILER=clang, CONFIGURATION=--verbose, ENVIRONMENT=GLOG_v=1, MESOS_VERBOSE=1,
OS=ubuntu:14.04, label_exp=docker||Hadoop/1638/changes
3) Recently a new ticket with a similar error has cropped up (MESOS-4604), but
we have diagnosed this problem already and it is unrelated to the errors seen
in this test (details are in the ticket itself).
was (Author: klueska):
I am marking this ticket as closed for the following reasons. If you feel this
is in error, please reopen it with specific details and a way to reproduce the
bug. Thanks!
1) Unfortunately, we don't have archives of the Jenkins builds before April
2015, so I don't have any easy way of seeing the exact last time this error
occurred. However, we do know it has not cropped up on the Jenkins builds
since at least December 2015:
http://www.mail-archive.com/search?q=pure+virtual&l=builds%40mesos.apache.org
2) As suggested above, I reset my Mesos tree to:
{noformat}
commit 5d5b65e5722a21868315d80eb05428b11b4d87d0
Author: Adam B
Date: Mon Oct 13 21:33:11 2014 -0700
Enabled whitespace/semicolon rule for cpplint.
{noformat}
and ran the following command, trying to trigger the "RAW: Pure virtual method
called" error for the two test mentioned in this thread as well as the test
mentioned in the related issue (MESOS-2007).
GTEST_FILTER="DRFAllocatorTest.DRFAllocatorProcess:ReconciliationTest.TaskStateMismatch:AllocatorTest/0.SlaveReregistersFirst"
run-one-until-failure src/mesos-tests --verbose
I ran this test continuously overnight on 2 different setups without error:
-- My native Mac OS X setup
-- A docker container based on the support/docker_build.sh script in newer
Mesoses.
I set up the docker with the following configuration:
COMPILER=clang, CONFIGURATION=--verbose, ENVIRONMENT=GLOG_v=1, MESOS_VERBOSE=1,
OS=ubuntu:14.04, label_exp=docker||Hadoop/1638/changes
3) Recently a new ticket with a similar error has cropped up (MESOS-4604), but
we have diagnosed this problem already and it is unrelated to the errors seen
in this test (details are in the ticket itself).
> Segfault with "Pure virtual method called" when tests fail
> --
>
> Key: MESOS-2017
> URL: https://issues.apache.org/jira/browse/MESOS-2017
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: mesosphere, tests
>
> The most recent one:
> {noformat:title=DRFAllocatorTest.DRFAllocatorProcess}
> [ RUN ] DRFAllocatorTest.DRFAllocatorProcess
> Using temporary directory '/tmp/DRFAllocatorTest_DRFAllocatorProcess_BI905j'
> I1030 05:55:06.934813 24459 leveldb.cpp:176] Opened db in 3.175202ms
> I1030 05:55:06.935925 24459 leveldb.cpp:183] Compacted db in 1.077924ms
> I1030 05:55:06.935976 24459 leveldb.cpp:198] Created db iterator in 16460ns
> I1030 05:55:06.935995 24459 leveldb.cpp:204] Seeked to beginning of db in
> 2018ns
> I1030 05:55:06.936005 24459 leveldb.cpp:273] Iterated through 0 keys in the
> db in 335ns
> I1030 05:55:06.936039 24459 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1030 05:55:06.936705 24480 recover.cpp:437] Starting replic
[jira] [Commented] (MESOS-2007) AllocatorTest/0.SlaveReregistersFirst is flaky
[
https://issues.apache.org/jira/browse/MESOS-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139472#comment-15139472
]
Kevin Klues commented on MESOS-2007:
I propose we mark this ticket closed for the following reasons. If you feel
this is in error, please reopen it with specific details and a way to reproduce
the bug. Thanks!
1) Unfortunately, we don't have archives of the Jenkins builds before April
2015, so I don't have any easy way of seeing the exact last time this error
occurred. However, we do know it has not cropped up on the Jenkins builds since
at least December 2015:
http://www.mail-archive.com/search?q=AllocatorTest&l=builds%40mesos.apache.org
2) As suggested in a related ticket (MESOS-2017), I reset my Mesos tree to:
{noformat}
commit 5d5b65e5722a21868315d80eb05428b11b4d87d0
Author: Adam B
Date: Mon Oct 13 21:33:11 2014 -0700
Enabled whitespace/semicolon rule for cpplint.
{noformat}
and ran the following command, trying to trigger both the flaky test error, as
well as the "RAW: Pure virtual method called" error.
GTEST_FILTER="DRFAllocatorTest.DRFAllocatorProcess:ReconciliationTest.TaskStateMismatch:AllocatorTest/0.SlaveReregistersFirst"
run-one-until-failure src/mesos-tests --verbose
I ran this test continuously overnight on 2 different setups without error:
– My native Mac OS X setup
– A docker container based on the support/docker_build.sh script in newer
Mesoses.
I set up the docker with the following configuration:
COMPILER=clang, CONFIGURATION=--verbose, ENVIRONMENT=GLOG_v=1, MESOS_VERBOSE=1,
OS=ubuntu:14.04, label_exp=docker||Hadoop/1638/changes
3) Recently a new ticket with a similar error has cropped up with a similar
"RAW: Pure virtual method called" error (MESOS-4604), but we have diagnosed
this problem already and it is unrelated to the errors seen in this test
(details are in the ticket itself).
> AllocatorTest/0.SlaveReregistersFirst is flaky
> --
>
> Key: MESOS-2007
> URL: https://issues.apache.org/jira/browse/MESOS-2007
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
> Environment: https://builds.apache.org/computer/ubuntu-1/systemInfo
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: flaky
>
> {noformat:title=}
> [ RUN ] AllocatorTest/0.SlaveReregistersFirst
> Using temporary directory '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d'
> I1028 23:48:22.360447 31190 leveldb.cpp:176] Opened db in 2.192575ms
> I1028 23:48:22.361253 31190 leveldb.cpp:183] Compacted db in 760753ns
> I1028 23:48:22.361320 31190 leveldb.cpp:198] Created db iterator in 22188ns
> I1028 23:48:22.361340 31190 leveldb.cpp:204] Seeked to beginning of db in
> 1950ns
> I1028 23:48:22.361351 31190 leveldb.cpp:273] Iterated through 0 keys in the
> db in 345ns
> I1028 23:48:22.361403 31190 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1028 23:48:22.362185 31217 recover.cpp:437] Starting replica recovery
> I1028 23:48:22.362764 31219 recover.cpp:463] Replica is in EMPTY status
> I1028 23:48:22.363955 31210 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1028 23:48:22.364320 31217 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1028 23:48:22.364820 31211 recover.cpp:554] Updating replica status to
> STARTING
> I1028 23:48:22.365365 31215 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 418991ns
> I1028 23:48:22.365391 31215 replica.cpp:320] Persisted replica status to
> STARTING
> I1028 23:48:22.365617 31217 recover.cpp:463] Replica is in STARTING status
> I1028 23:48:22.366328 31206 master.cpp:312] Master
> 20141028-234822-3193029443-50043-31190 (pietas.apache.org) started on
> 67.195.81.190:50043
> I1028 23:48:22.366377 31206 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1028 23:48:22.366391 31206 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1028 23:48:22.366402 31206 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d/credentials'
> I1028 23:48:22.366708 31206 master.cpp:392] Authorization enabled
> I1028 23:48:22.366886 31209 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1028 23:48:22.367311 31208 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1028 23:48:22.367312 31207 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1028 23:48:22.367686 31211 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.190:50043
> I1028 23:48:22.367863 31212 recover.cpp:55
[jira] [Updated] (MESOS-2007) AllocatorTest/0.SlaveReregistersFirst is flaky
[
https://issues.apache.org/jira/browse/MESOS-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2007:
---
Shepherd: Benjamin Mahler
Sprint: Mesosphere Sprint 28
Story Points: 2
> AllocatorTest/0.SlaveReregistersFirst is flaky
> --
>
> Key: MESOS-2007
> URL: https://issues.apache.org/jira/browse/MESOS-2007
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
> Environment: https://builds.apache.org/computer/ubuntu-1/systemInfo
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: flaky
>
> {noformat:title=}
> [ RUN ] AllocatorTest/0.SlaveReregistersFirst
> Using temporary directory '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d'
> I1028 23:48:22.360447 31190 leveldb.cpp:176] Opened db in 2.192575ms
> I1028 23:48:22.361253 31190 leveldb.cpp:183] Compacted db in 760753ns
> I1028 23:48:22.361320 31190 leveldb.cpp:198] Created db iterator in 22188ns
> I1028 23:48:22.361340 31190 leveldb.cpp:204] Seeked to beginning of db in
> 1950ns
> I1028 23:48:22.361351 31190 leveldb.cpp:273] Iterated through 0 keys in the
> db in 345ns
> I1028 23:48:22.361403 31190 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1028 23:48:22.362185 31217 recover.cpp:437] Starting replica recovery
> I1028 23:48:22.362764 31219 recover.cpp:463] Replica is in EMPTY status
> I1028 23:48:22.363955 31210 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1028 23:48:22.364320 31217 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1028 23:48:22.364820 31211 recover.cpp:554] Updating replica status to
> STARTING
> I1028 23:48:22.365365 31215 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 418991ns
> I1028 23:48:22.365391 31215 replica.cpp:320] Persisted replica status to
> STARTING
> I1028 23:48:22.365617 31217 recover.cpp:463] Replica is in STARTING status
> I1028 23:48:22.366328 31206 master.cpp:312] Master
> 20141028-234822-3193029443-50043-31190 (pietas.apache.org) started on
> 67.195.81.190:50043
> I1028 23:48:22.366377 31206 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1028 23:48:22.366391 31206 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1028 23:48:22.366402 31206 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d/credentials'
> I1028 23:48:22.366708 31206 master.cpp:392] Authorization enabled
> I1028 23:48:22.366886 31209 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1028 23:48:22.367311 31208 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1028 23:48:22.367312 31207 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1028 23:48:22.367686 31211 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.190:50043
> I1028 23:48:22.367863 31212 recover.cpp:554] Updating replica status to VOTING
> I1028 23:48:22.368477 31218 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 375527ns
> I1028 23:48:22.368505 31218 replica.cpp:320] Persisted replica status to
> VOTING
> I1028 23:48:22.368517 31204 master.cpp:1242] The newly elected leader is
> master@67.195.81.190:50043 with id 20141028-234822-3193029443-50043-31190
> I1028 23:48:22.368549 31204 master.cpp:1255] Elected as the leading master!
> I1028 23:48:22.368567 31204 master.cpp:1073] Recovering from registrar
> I1028 23:48:22.368621 31215 recover.cpp:568] Successfully joined the Paxos
> group
> I1028 23:48:22.368716 31219 registrar.cpp:313] Recovering registrar
> I1028 23:48:22.369000 31215 recover.cpp:452] Recover process terminated
> I1028 23:48:22.369523 31208 log.cpp:656] Attempting to start the writer
> I1028 23:48:22.370909 31205 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1028 23:48:22.371266 31205 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 325016ns
> I1028 23:48:22.371290 31205 replica.cpp:342] Persisted promised to 1
> I1028 23:48:22.371979 31218 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1028 23:48:22.373378 31210 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1028 23:48:22.373746 31210 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 329018ns
> I1028 23:48:22.373772 31210 replica.cpp:676] Persisted action at 0
> I1028 23:48:22.374897 31214 replica.cpp:508] Replica received write request
> for position 0
> I1028 23:48:22.374951 31214 leveldb.cpp:438] Reading position from leveldb
> to
[jira] [Updated] (MESOS-2007) AllocatorTest/0.SlaveReregistersFirst is flaky
[
https://issues.apache.org/jira/browse/MESOS-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-2007:
---
Labels: flaky mesosphere (was: flaky)
> AllocatorTest/0.SlaveReregistersFirst is flaky
> --
>
> Key: MESOS-2007
> URL: https://issues.apache.org/jira/browse/MESOS-2007
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.21.0
> Environment: https://builds.apache.org/computer/ubuntu-1/systemInfo
>Reporter: Yan Xu
>Assignee: Kevin Klues
> Labels: flaky, mesosphere
>
> {noformat:title=}
> [ RUN ] AllocatorTest/0.SlaveReregistersFirst
> Using temporary directory '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d'
> I1028 23:48:22.360447 31190 leveldb.cpp:176] Opened db in 2.192575ms
> I1028 23:48:22.361253 31190 leveldb.cpp:183] Compacted db in 760753ns
> I1028 23:48:22.361320 31190 leveldb.cpp:198] Created db iterator in 22188ns
> I1028 23:48:22.361340 31190 leveldb.cpp:204] Seeked to beginning of db in
> 1950ns
> I1028 23:48:22.361351 31190 leveldb.cpp:273] Iterated through 0 keys in the
> db in 345ns
> I1028 23:48:22.361403 31190 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1028 23:48:22.362185 31217 recover.cpp:437] Starting replica recovery
> I1028 23:48:22.362764 31219 recover.cpp:463] Replica is in EMPTY status
> I1028 23:48:22.363955 31210 replica.cpp:638] Replica in EMPTY status received
> a broadcasted recover request
> I1028 23:48:22.364320 31217 recover.cpp:188] Received a recover response from
> a replica in EMPTY status
> I1028 23:48:22.364820 31211 recover.cpp:554] Updating replica status to
> STARTING
> I1028 23:48:22.365365 31215 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 418991ns
> I1028 23:48:22.365391 31215 replica.cpp:320] Persisted replica status to
> STARTING
> I1028 23:48:22.365617 31217 recover.cpp:463] Replica is in STARTING status
> I1028 23:48:22.366328 31206 master.cpp:312] Master
> 20141028-234822-3193029443-50043-31190 (pietas.apache.org) started on
> 67.195.81.190:50043
> I1028 23:48:22.366377 31206 master.cpp:358] Master only allowing
> authenticated frameworks to register
> I1028 23:48:22.366391 31206 master.cpp:363] Master only allowing
> authenticated slaves to register
> I1028 23:48:22.366402 31206 credentials.hpp:36] Loading credentials for
> authentication from
> '/tmp/AllocatorTest_0_SlaveReregistersFirst_YPe61d/credentials'
> I1028 23:48:22.366708 31206 master.cpp:392] Authorization enabled
> I1028 23:48:22.366886 31209 replica.cpp:638] Replica in STARTING status
> received a broadcasted recover request
> I1028 23:48:22.367311 31208 master.cpp:120] No whitelist given. Advertising
> offers for all slaves
> I1028 23:48:22.367312 31207 recover.cpp:188] Received a recover response from
> a replica in STARTING status
> I1028 23:48:22.367686 31211 hierarchical_allocator_process.hpp:299]
> Initializing hierarchical allocator process with master :
> master@67.195.81.190:50043
> I1028 23:48:22.367863 31212 recover.cpp:554] Updating replica status to VOTING
> I1028 23:48:22.368477 31218 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 375527ns
> I1028 23:48:22.368505 31218 replica.cpp:320] Persisted replica status to
> VOTING
> I1028 23:48:22.368517 31204 master.cpp:1242] The newly elected leader is
> master@67.195.81.190:50043 with id 20141028-234822-3193029443-50043-31190
> I1028 23:48:22.368549 31204 master.cpp:1255] Elected as the leading master!
> I1028 23:48:22.368567 31204 master.cpp:1073] Recovering from registrar
> I1028 23:48:22.368621 31215 recover.cpp:568] Successfully joined the Paxos
> group
> I1028 23:48:22.368716 31219 registrar.cpp:313] Recovering registrar
> I1028 23:48:22.369000 31215 recover.cpp:452] Recover process terminated
> I1028 23:48:22.369523 31208 log.cpp:656] Attempting to start the writer
> I1028 23:48:22.370909 31205 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1028 23:48:22.371266 31205 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 325016ns
> I1028 23:48:22.371290 31205 replica.cpp:342] Persisted promised to 1
> I1028 23:48:22.371979 31218 coordinator.cpp:230] Coordinator attemping to
> fill missing position
> I1028 23:48:22.373378 31210 replica.cpp:375] Replica received explicit
> promise request for position 0 with proposal 2
> I1028 23:48:22.373746 31210 leveldb.cpp:343] Persisting action (8 bytes) to
> leveldb took 329018ns
> I1028 23:48:22.373772 31210 replica.cpp:676] Persisted action at 0
> I1028 23:48:22.374897 31214 replica.cpp:508] Replica received write request
> for position 0
> I1028 23:48:22.374951 31214 leveldb.cpp:438] Reading position from leveldb
> took 26002ns
> I1028 23:48:22.375272 312
[jira] [Commented] (MESOS-3831) Document operator HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139813#comment-15139813
]
Kevin Klues commented on MESOS-3831:
I still think this should be included, it just wasn't part of the initial push
to get "some" documentation out there. Maybe we should create a separate
ticket for this.
> Document operator HTTP endpoints
>
>
> Key: MESOS-3831
> URL: https://issues.apache.org/jira/browse/MESOS-3831
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Neil Conway
>Assignee: Kevin Klues
>Priority: Minor
> Labels: documentation, mesosphere, newbie
> Fix For: 0.28.0
>
>
> These are not exhaustively documented; they probably should be.
> Some endpoints have docs: e.g., {{/reserve}} and {{/unreserve}} are described
> in the reservation doc page. But it would be good to have a single page that
> lists all the endpoints and their semantics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-7576) Add master flag `--filter-gpu-resources={true|false}`
Kevin Klues created MESOS-7576:
--
Summary: Add master flag `--filter-gpu-resources={true|false}`
Key: MESOS-7576
URL: https://issues.apache.org/jira/browse/MESOS-7576
Project: Mesos
Issue Type: Task
Components: gpu
Affects Versions: 1.2.0
Reporter: Kevin Klues
Assignee: Kevin Klues
Per the email thread below, we are adding a new flag on the master called
{{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
framework capability.
https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
When set to {{true}}, this flag will cause the mesos master to continue to
function as it does today. That is, it will filter offers containing GPU
resources and only send them to frameworks that opt into the {{GPU_RESOURCES}}
framework capability. When set to {{false}}, this flag will cause the master to
*not* filter offers containing GPU resources, and indiscriminately send them to
all frameworks whether they set the {{GPU_RESOURCES}} capability or not.
This is a temporary flag that will eventually be removed. We will remove it
once we have better support for achieving the same functionality that the
{{GPU_RESOURCES}} capability gives you.
As described in the email, this support relies {{reservations}}, {{hierarchical
roles}}, and support for {{reservations to multiple roles}} (an unyet
implemented feature). The JIRA tracking these features are linked below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7576) Add master flag `--filter-gpu-resources={true|false}`
[
https://issues.apache.org/jira/browse/MESOS-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7576:
---
Description:
Per the email thread below, we are adding a new flag on the master called
{{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
framework capability.
https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
When set to {{true}}, this flag will cause the mesos master to continue to
function as it does today. That is, it will filter offers containing GPU
resources and only send them to frameworks that opt into the {{GPU_RESOURCES}}
framework capability. When set to {{false}}, this flag will cause the master to
*not* filter offers containing GPU resources, and indiscriminately send them to
all frameworks whether they set the {{GPU_RESOURCES}} capability or not.
This is a temporary flag that will eventually be removed. We will remove it
once we have better support for achieving the same functionality that the
{{GPU_RESOURCES}} capability gives you.
As described in the email, this support relies {{dynamic reservations}},
{{hierarchical roles}}, and support for {{reservations to multiple roles}} (an
unyet implemented feature). The JIRA tracking these features are linked below.
was:
Per the email thread below, we are adding a new flag on the master called
{{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
framework capability.
https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
When set to {{true}}, this flag will cause the mesos master to continue to
function as it does today. That is, it will filter offers containing GPU
resources and only send them to frameworks that opt into the {{GPU_RESOURCES}}
framework capability. When set to {{false}}, this flag will cause the master to
*not* filter offers containing GPU resources, and indiscriminately send them to
all frameworks whether they set the {{GPU_RESOURCES}} capability or not.
This is a temporary flag that will eventually be removed. We will remove it
once we have better support for achieving the same functionality that the
{{GPU_RESOURCES}} capability gives you.
As described in the email, this support relies {{reservations}}, {{hierarchical
roles}}, and support for {{reservations to multiple roles}} (an unyet
implemented feature). The JIRA tracking these features are linked below.
> Add master flag `--filter-gpu-resources={true|false}`
> -
>
> Key: MESOS-7576
> URL: https://issues.apache.org/jira/browse/MESOS-7576
> Project: Mesos
> Issue Type: Task
> Components: gpu
>Affects Versions: 1.2.0
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>
> Per the email thread below, we are adding a new flag on the master called
> {{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
> framework capability.
> https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
> When set to {{true}}, this flag will cause the mesos master to continue to
> function as it does today. That is, it will filter offers containing GPU
> resources and only send them to frameworks that opt into the
> {{GPU_RESOURCES}} framework capability. When set to {{false}}, this flag will
> cause the master to *not* filter offers containing GPU resources, and
> indiscriminately send them to all frameworks whether they set the
> {{GPU_RESOURCES}} capability or not.
> This is a temporary flag that will eventually be removed. We will remove it
> once we have better support for achieving the same functionality that the
> {{GPU_RESOURCES}} capability gives you.
> As described in the email, this support relies {{dynamic reservations}},
> {{hierarchical roles}}, and support for {{reservations to multiple roles}}
> (an unyet implemented feature). The JIRA tracking these features are linked
> below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7576) Add master flag `--filter-gpu-resources={true|false}`
[
https://issues.apache.org/jira/browse/MESOS-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7576:
---
Description:
Per the email thread below, we are adding a new flag on the master called
{{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
framework capability.
https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
When set to {{true}}, this flag will cause the mesos master to continue to
function as it does today. That is, it will filter offers containing GPU
resources and only send them to frameworks that opt into the {{GPU_RESOURCES}}
framework capability. When set to {{false}}, this flag will cause the master to
*not* filter offers containing GPU resources, and indiscriminately send them to
all frameworks whether they set the {{GPU_RESOURCES}} capability or not.
This is a temporary flag that will eventually be removed. We will remove it
once we have better support for achieving the same functionality that the
{{GPU_RESOURCES}} capability gives you.
As described in the email, this support relies on {{dynamic reservations}},
{{hierarchical roles}}, and support for {{reservations to multiple roles}} (an
unyet implemented feature). The JIRA tracking these features are linked below.
was:
Per the email thread below, we are adding a new flag on the master called
{{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
framework capability.
https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
When set to {{true}}, this flag will cause the mesos master to continue to
function as it does today. That is, it will filter offers containing GPU
resources and only send them to frameworks that opt into the {{GPU_RESOURCES}}
framework capability. When set to {{false}}, this flag will cause the master to
*not* filter offers containing GPU resources, and indiscriminately send them to
all frameworks whether they set the {{GPU_RESOURCES}} capability or not.
This is a temporary flag that will eventually be removed. We will remove it
once we have better support for achieving the same functionality that the
{{GPU_RESOURCES}} capability gives you.
As described in the email, this support relies {{dynamic reservations}},
{{hierarchical roles}}, and support for {{reservations to multiple roles}} (an
unyet implemented feature). The JIRA tracking these features are linked below.
> Add master flag `--filter-gpu-resources={true|false}`
> -
>
> Key: MESOS-7576
> URL: https://issues.apache.org/jira/browse/MESOS-7576
> Project: Mesos
> Issue Type: Task
> Components: gpu
>Affects Versions: 1.2.0
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>
> Per the email thread below, we are adding a new flag on the master called
> {{--filter-gpu-resources}} to enable / disable honoring the {{GPU_RESOURCES}}
> framework capability.
> https://www.mail-archive.com/dev@mesos.apache.org/msg37571.html
> When set to {{true}}, this flag will cause the mesos master to continue to
> function as it does today. That is, it will filter offers containing GPU
> resources and only send them to frameworks that opt into the
> {{GPU_RESOURCES}} framework capability. When set to {{false}}, this flag will
> cause the master to *not* filter offers containing GPU resources, and
> indiscriminately send them to all frameworks whether they set the
> {{GPU_RESOURCES}} capability or not.
> This is a temporary flag that will eventually be removed. We will remove it
> once we have better support for achieving the same functionality that the
> {{GPU_RESOURCES}} capability gives you.
> As described in the email, this support relies on {{dynamic reservations}},
> {{hierarchical roles}}, and support for {{reservations to multiple roles}}
> (an unyet implemented feature). The JIRA tracking these features are linked
> below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7577) Remove master flag `--filter-gpu-resources={true|false}`
Kevin Klues created MESOS-7577:
--
Summary: Remove master flag `--filter-gpu-resources={true|false}`
Key: MESOS-7577
URL: https://issues.apache.org/jira/browse/MESOS-7577
Project: Mesos
Issue Type: Task
Components: allocation, gpu
Reporter: Kevin Klues
This flag was added as a temporary way to to enable / disable honoring the
GPU_RESOURCES framework capability. We should remove it once we have better
support for achieving the same functionality that the GPU_RESOURCES capability
gives you.
This support relies on dynamic reservations, hierarchical roles, and support
for reservations to multiple roles (an unyet implemented feature). The JIRA
tracking these features as blockers to this ticket are linked below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7577) Remove GPU_RESOURCES capability and master flag `--filter-gpu-resources={true|false}`
[
https://issues.apache.org/jira/browse/MESOS-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7577:
---
Summary: Remove GPU_RESOURCES capability and master flag
`--filter-gpu-resources={true|false}` (was: Remove GPU_RESOURCES capability
and remove master flag `--filter-gpu-resources={true|false}`)
> Remove GPU_RESOURCES capability and master flag
> `--filter-gpu-resources={true|false}`
> -
>
> Key: MESOS-7577
> URL: https://issues.apache.org/jira/browse/MESOS-7577
> Project: Mesos
> Issue Type: Task
> Components: allocation, gpu
>Reporter: Kevin Klues
>
> This flag was added as a temporary way to to enable / disable honoring the
> GPU_RESOURCES framework capability. We should remove it once we have better
> support for achieving the same functionality that the GPU_RESOURCES
> capability gives you.
> This support relies on dynamic reservations, hierarchical roles, and support
> for reservations to multiple roles (an unyet implemented feature). The JIRA
> tracking these features as blockers to this ticket are linked below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7577) Remove GPU_RESOURCES capability and remove master flag `--filter-gpu-resources={true|false}`
[
https://issues.apache.org/jira/browse/MESOS-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7577:
---
Summary: Remove GPU_RESOURCES capability and remove master flag
`--filter-gpu-resources={true|false}` (was: Remove master flag
`--filter-gpu-resources={true|false}`)
> Remove GPU_RESOURCES capability and remove master flag
> `--filter-gpu-resources={true|false}`
>
>
> Key: MESOS-7577
> URL: https://issues.apache.org/jira/browse/MESOS-7577
> Project: Mesos
> Issue Type: Task
> Components: allocation, gpu
>Reporter: Kevin Klues
>
> This flag was added as a temporary way to to enable / disable honoring the
> GPU_RESOURCES framework capability. We should remove it once we have better
> support for achieving the same functionality that the GPU_RESOURCES
> capability gives you.
> This support relies on dynamic reservations, hierarchical roles, and support
> for reservations to multiple roles (an unyet implemented feature). The JIRA
> tracking these features as blockers to this ticket are linked below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7579) Deprecate GPU_RESOURCES capability and master flag `--filter-gpu-resources={true|false}`
Kevin Klues created MESOS-7579:
--
Summary: Deprecate GPU_RESOURCES capability and master flag
`--filter-gpu-resources={true|false}`
Key: MESOS-7579
URL: https://issues.apache.org/jira/browse/MESOS-7579
Project: Mesos
Issue Type: Task
Components: allocation, gpu
Reporter: Kevin Klues
Once we reach Mesos 2.0, we should completely remove the GPU_RESOURCES
capability and the corresponding {{--filter-gpu-resources}} that controls
whether the allocator honors this capability or not.
It will have been deprecated once support for {{dynamic reservations}},
{{hierarchical roles}}, and {{support for reservations to multiple roles}} has
landed. The JIRA tracking these features as blockers to this ticket are linked
below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7577) Remove GPU_RESOURCES capability and master flag `--filter-gpu-resources={true|false}`
[
https://issues.apache.org/jira/browse/MESOS-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7577:
---
Target Version/s: 2.1.0
Description:
Once we reach Mesos 2.0, we should completely remove the GPU_RESOURCES
capability and the corresponding {{--filter-gpu-resources}} that controls
whether the allocator honors this capability or not.
It will have been deprecated once support for {{dynamic reservations}},
{{hierarchical roles}}, and {{support for reservations to multiple roles}} has
landed. The JIRA tracking these features as blockers to this ticket are linked
below.
was:
This flag was added as a temporary way to to enable / disable honoring the
GPU_RESOURCES framework capability. We should remove it once we have better
support for achieving the same functionality that the GPU_RESOURCES capability
gives you.
This support relies on dynamic reservations, hierarchical roles, and support
for reservations to multiple roles (an unyet implemented feature). The JIRA
tracking these features as blockers to this ticket are linked below.
> Remove GPU_RESOURCES capability and master flag
> `--filter-gpu-resources={true|false}`
> -
>
> Key: MESOS-7577
> URL: https://issues.apache.org/jira/browse/MESOS-7577
> Project: Mesos
> Issue Type: Task
> Components: allocation, gpu
>Reporter: Kevin Klues
>
> Once we reach Mesos 2.0, we should completely remove the GPU_RESOURCES
> capability and the corresponding {{--filter-gpu-resources}} that controls
> whether the allocator honors this capability or not.
> It will have been deprecated once support for {{dynamic reservations}},
> {{hierarchical roles}}, and {{support for reservations to multiple roles}}
> has landed. The JIRA tracking these features as blockers to this ticket are
> linked below.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7582) Add Config class to manage the Mesos CLI config file.
Kevin Klues created MESOS-7582: -- Summary: Add Config class to manage the Mesos CLI config file. Key: MESOS-7582 URL: https://issues.apache.org/jira/browse/MESOS-7582 Project: Mesos Issue Type: Task Components: cli Reporter: Kevin Klues Assignee: Armand Grillet This new class will simplify the management of the configuration file given by the user; it will load the TOML file on initialization and have one method for each element that the user can set. This new class and its associated content should also be passed to the plugins at initialization so that they can read the user configuration and use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-7582) Add Config class to manage the Mesos CLI config file.
[
https://issues.apache.org/jira/browse/MESOS-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028292#comment-16028292
]
Kevin Klues commented on MESOS-7582:
{noformat}
commit f6c2ee0df8a3170d6cd211211c5ab2e50802efde
Author: Kevin Klues
Date: Mon May 29 05:28:27 2017 -0700
Moved 'current_word' calculation for autocomplete in the new Mesos CLI.
{noformat}
{noformat}
commit 8740ce8d3adc723162350f35b5508d811214ac7e
Author: Armand Grillet
Date: Mon May 29 05:12:33 2017 -0700
Added Config class to manage the config file in the new Mesos CLI.
This new class simplifies the management of the configuration file
given by the user; it loads the TOML file on initialization and
has one method for each element that the user can set.
This new class and its associated content is also passed to the
plugins at initialization so that they can read the user configuration
and use it.
Review: https://reviews.apache.org/r/59177/
{noformat}
> Add Config class to manage the Mesos CLI config file.
> -
>
> Key: MESOS-7582
> URL: https://issues.apache.org/jira/browse/MESOS-7582
> Project: Mesos
> Issue Type: Task
> Components: cli
>Reporter: Kevin Klues
>Assignee: Armand Grillet
>
> This new class will simplify the management of the configuration file given
> by the user; it will load the TOML file on initialization and have one method
> for each element that the user can set.
> This new class and its associated content should also be passed to the
> plugins at initialization so that they can read the user configuration and
> use it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7584) ASF Jenkins build errors out on missing 'pyton-six' dependency
Kevin Klues created MESOS-7584:
--
Summary: ASF Jenkins build errors out on missing 'pyton-six'
dependency
Key: MESOS-7584
URL: https://issues.apache.org/jira/browse/MESOS-7584
Project: Mesos
Issue Type: Bug
Components: build
Reporter: Kevin Klues
Assignee: Kevin Klues
Priority: Blocker
{noformat}
[ RUN ] ExamplesTest.PythonFramework
Using temporary directory '/tmp/ExamplesTest_PythonFramework_T0LN9L'
Traceback (most recent call last):
File "/mesos/mesos-1.4.0/_build/../src/examples/python/test_framework.py",
line 24, in
from mesos.interface import mesos_pb2
File "build/bdist.linux-x86_64/egg/mesos/interface/mesos_pb2.py", line 7, in
File
"/mesos/mesos-1.4.0/_build/3rdparty/protobuf-3.3.0/python/google/protobuf/descriptor.py",
line 37, in
import six
ImportError: No module named six
../../src/tests/script.cpp:83: Failure
Failed
python_framework_test.sh exited with status 1
[ FAILED ] ExamplesTest.PythonFramework (149 ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7584) ASF Jenkins build errors out on missing 'python-six' dependency
[
https://issues.apache.org/jira/browse/MESOS-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7584:
---
Summary: ASF Jenkins build errors out on missing 'python-six' dependency
(was: ASF Jenkins build errors out on missing 'pyton-six' dependency)
> ASF Jenkins build errors out on missing 'python-six' dependency
> ---
>
> Key: MESOS-7584
> URL: https://issues.apache.org/jira/browse/MESOS-7584
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>Priority: Blocker
>
> {noformat}
> [ RUN ] ExamplesTest.PythonFramework
> Using temporary directory '/tmp/ExamplesTest_PythonFramework_T0LN9L'
> Traceback (most recent call last):
> File "/mesos/mesos-1.4.0/_build/../src/examples/python/test_framework.py",
> line 24, in
> from mesos.interface import mesos_pb2
> File "build/bdist.linux-x86_64/egg/mesos/interface/mesos_pb2.py", line 7,
> in
> File
> "/mesos/mesos-1.4.0/_build/3rdparty/protobuf-3.3.0/python/google/protobuf/descriptor.py",
> line 37, in
> import six
> ImportError: No module named six
> ../../src/tests/script.cpp:83: Failure
> Failed
> python_framework_test.sh exited with status 1
> [ FAILED ] ExamplesTest.PythonFramework (149 ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7584) ASF Jenkins build errors out on missing 'pyton-six' dependency
[
https://issues.apache.org/jira/browse/MESOS-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028619#comment-16028619
]
Kevin Klues commented on MESOS-7584:
{noformat}
commit 8ea46990999b61d7d79a23b582b5eb7d586bd164
Author: Kevin Klues
Date: Mon May 29 12:04:23 2017 -0700
Added 'python-six' to the list of build dependencies.
Review: https://reviews.apache.org/r/59632
{noformat}
> ASF Jenkins build errors out on missing 'pyton-six' dependency
> --
>
> Key: MESOS-7584
> URL: https://issues.apache.org/jira/browse/MESOS-7584
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>Priority: Blocker
>
> {noformat}
> [ RUN ] ExamplesTest.PythonFramework
> Using temporary directory '/tmp/ExamplesTest_PythonFramework_T0LN9L'
> Traceback (most recent call last):
> File "/mesos/mesos-1.4.0/_build/../src/examples/python/test_framework.py",
> line 24, in
> from mesos.interface import mesos_pb2
> File "build/bdist.linux-x86_64/egg/mesos/interface/mesos_pb2.py", line 7,
> in
> File
> "/mesos/mesos-1.4.0/_build/3rdparty/protobuf-3.3.0/python/google/protobuf/descriptor.py",
> line 37, in
> import six
> ImportError: No module named six
> ../../src/tests/script.cpp:83: Failure
> Failed
> python_framework_test.sh exited with status 1
> [ FAILED ] ExamplesTest.PythonFramework (149 ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7584) ASF Jenkins build errors out on missing 'python-six' dependency
[
https://issues.apache.org/jira/browse/MESOS-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues updated MESOS-7584:
---
Shepherd: Till Toenshoff (was: Kevin Klues)
> ASF Jenkins build errors out on missing 'python-six' dependency
> ---
>
> Key: MESOS-7584
> URL: https://issues.apache.org/jira/browse/MESOS-7584
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>Priority: Blocker
>
> {noformat}
> [ RUN ] ExamplesTest.PythonFramework
> Using temporary directory '/tmp/ExamplesTest_PythonFramework_T0LN9L'
> Traceback (most recent call last):
> File "/mesos/mesos-1.4.0/_build/../src/examples/python/test_framework.py",
> line 24, in
> from mesos.interface import mesos_pb2
> File "build/bdist.linux-x86_64/egg/mesos/interface/mesos_pb2.py", line 7,
> in
> File
> "/mesos/mesos-1.4.0/_build/3rdparty/protobuf-3.3.0/python/google/protobuf/descriptor.py",
> line 37, in
> import six
> ImportError: No module named six
> ../../src/tests/script.cpp:83: Failure
> Failed
> python_framework_test.sh exited with status 1
> [ FAILED ] ExamplesTest.PythonFramework (149 ms)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7585) Added 'mesos config show' command to the new Mesos CLI.
Kevin Klues created MESOS-7585: -- Summary: Added 'mesos config show' command to the new Mesos CLI. Key: MESOS-7585 URL: https://issues.apache.org/jira/browse/MESOS-7585 Project: Mesos Issue Type: Improvement Components: cli Reporter: Kevin Klues Assignee: Armand Grillet This command should display the contents of the user-defined config.toml file. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-7310) Implement a separate python client library for the new cli
[
https://issues.apache.org/jira/browse/MESOS-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16077041#comment-16077041
]
Kevin Klues commented on MESOS-7310:
{noformat}
commit 1b75c37cff41f1d6955e1b202f73193b57ea636f
Author: Eric Chung
Date: Thu Jul 6 10:54:37 2017 -0700
Setup new directory for importable python libs in src/python.
Part of MESOS-7310, this patch adds a new directory
(src/python/lib/mesos), which will be importable via 'import mesos'
from the cli.
Review: https://reviews.apache.org/r/58394/
{noformat}
> Implement a separate python client library for the new cli
> --
>
> Key: MESOS-7310
> URL: https://issues.apache.org/jira/browse/MESOS-7310
> Project: Mesos
> Issue Type: Task
> Components: cli
>Affects Versions: 1.3.0
>Reporter: Eric Chung
>Assignee: Eric Chung
>
> cli_new in its current form is very difficult to package due to the following
> reasons:
> 1. src/cli_new/lib/mesos imports plugins using relative imports, which fails
> if it is built into a pip package
> 2. there is no setup.py script which defines what should be installed
> 3. plugins/tests are unnecessarily included in the package, which are things
> consumers of the package shouldn’t be able to import
> having such a package will allow external consumers to be able to add
> application-specific wrappers on it, e.g. integration with ACL libraries of
> their choice.
> The plan as discussed will create a `mesos` package under `src/python/lib`,
> potentially including a `setup.py` for building the package into a PyPI
> package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-7730) CUDA not working anymore on 1.3.0
[
https://issues.apache.org/jira/browse/MESOS-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Klues reassigned MESOS-7730:
--
Assignee: Kevin Klues
> CUDA not working anymore on 1.3.0
> -
>
> Key: MESOS-7730
> URL: https://issues.apache.org/jira/browse/MESOS-7730
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.0
>Reporter: Adam Cecile
>Assignee: Kevin Klues
> Fix For: 1.2.1
>
>
> Hello,
> My docker container using CUDA do not detect it anymore.
> Here the tensorflow output with 1.2.1:
> {noformat}
> I0628 12:39:45.505900 16309 exec.cpp:162] Version: 1.2.1
> I0628 12:39:45.508358 16301 exec.cpp:237] Executor registered on agent
> 84c99d0b-8551-4f30-a9bc-6c1edbf7c18c-S1
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcublas.so.8.0 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcudnn.so.5 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcufft.so.8.0 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcuda.so.1 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcurand.so.8.0 locally
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use SSE3 instructions, but these are available on your
> machine and could speed up CPU computations.
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use SSE4.1 instructions, but these are available on your
> machine and could speed up CPU computations.
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use SSE4.2 instructions, but these are available on your
> machine and could speed up CPU computations.
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use AVX instructions, but these are available on your
> machine and could speed up CPU computations.
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use AVX2 instructions, but these are available on your
> machine and could speed up CPU computations.
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library
> wasn't compiled to use FMA instructions, but these are available on your
> machine and could speed up CPU computations.
> I tensorflow/core/common_runtime/gpu/gpu_device.cc:885] Found device 0 with
> properties:
> name: GeForce GTX 1080
> major: 6 minor: 1 memoryClockRate (GHz) 1.7335
> pciBusID :82:00.0
> Total memory: 7.92GiB
> Free memory: 7.81GiB
> I tensorflow/core/common_runtime/gpu/gpu_device.cc:906] DMA: 0
> I tensorflow/core/common_runtime/gpu/gpu_device.cc:916] 0: Y
> I tensorflow/core/common_runtime/gpu/gpu_device.cc:975] Creating TensorFlow
> device (/gpu:0) -> (device: 0, name: GeForce GTX 1080, pci bus id:
> :82:00.0)
> {noformat}
> And with 1.3.0
> {noformat}
> I0628 12:40:30.833947 16854 exec.cpp:162] Version: 1.3.0
> I0628 12:40:30.836612 16845 exec.cpp:237] Executor registered on agent
> 84c99d0b-8551-4f30-a9bc-6c1edbf7c18c-S1
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcublas.so.8.0 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcudnn.so.5 locally
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcufft.so.8.0 locally
> I tensorflow/stream_executor/dso_loader.cc:126] Couldn't open CUDA library
> libcuda.so.1. LD_LIBRARY_PATH:
> I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:165] hostname:
> zelda.service.earthlab.lu
> I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:189] libcuda reported
> version is: Not found: was unable to find libcuda.so DSO loaded into this
> program
> I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:363] driver version
> file contents: """NVRM version: NVIDIA UNIX x86_64 Kernel Module 375.66 Mon
> May 1 15:29:16 PDT 2017
> GCC version: gcc version 4.9.2 (Debian 4.9.2-10)
> """
> I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:193] kernel reported
> version is: 375.66.0
> I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:1065] LD_LIBRARY_PATH:
> I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:1066] failed to find
> libcuda.so on this system: Failed precondition: could not dlopen DSO:
> libcuda.so.1; dlerror: libcuda.so.1: cannot open shared object file: No such
> file or directory
> I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA
> library libcurand.so.8.0 locally
> W tensorflow/core/platform/cpu_feature_guard.cc:45] The
