Re: Speed up Mesos tests

[Neil Conway]

+1 on the speed-up-the-tests project!

On Wed, Dec 16, 2015 at 10:29 AM, Greg Mann  wrote:
> I'd like to bring up something that both Neil and Joseph mentioned to me
> recently, which could be of use when working on these slow test tickets.
> Since we have the `process::Clock` class, it's quite easy to control the
> clock manually, and doing so can both speed up tests as well as make them
> more deterministic/less flaky. While we're working on the above tickets, I
> think it would be nice to look for opportunities to alter the tests we're
> touching to pause the clock and then advance it explicitly using `pause()`,
> `settle()`, and `advance()`, rather than letting it run as usual.

Yep -- I think eventually having the clock paused by default for tests
would probably be a good idea:

https://issues.apache.org/jira/browse/MESOS-4101

To make that happen, we might need a few more primitives to force
"pending" events to be processed before manually advancing the clock.
`Clock::settle()` works for libprocess messages, but not for socket
communication more generally (e.g., when using the HTTP API). It would
help to get rid of this kludge in `Clock::settle` as well:

https://issues.apache.org/jira/browse/MESOS-3760

Neil

Jenkins builds failing for CentOS 7

[Kevin Klues]

Hey all,

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

I ran into this problem a few days ago while building a vagrant box
for centos 7.  The problem is summarized in this review request:

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

I'm not familiar with how the docker images for the build are
launched, but it seems they need to be updated in a manner similar to
what I propose in the updated getting started guide in the review.

-- 
~Kevin

Re: Speed up Mesos tests

[tommy xiao]

+1

2015-12-16 2:15 GMT+08:00 Alex Rukletsov :

> Folks,
>
> I would like to share some facts and thoughts about tests. When I ran `make
> check -j7` on my Mac OS machine the other day, gtest reported the following
> (your numbers may vary depending on the OS you're on and filters you use):
> [==] 882 tests from 117 test cases ran. (298610 ms total)
>
> Same command for Mesos 0.21.1, which has been released around a year ago,
> yields
> [==] 452 tests from 71 test cases ran. (196398 ms total)
>
> We almost doubled the number of tests in 2015. I think this is a great
> achievement per se, moreover it makes the life of cluster operators,
> release managers, and Mesos contributors less stressful. I am going to have
> an extra glass of champagne to celebrate this at the upcoming New Year Eve
> : ).
>
> There are still some flaky tests left — and there always will be, failure
> is embedded into progress —, but it is not the flakiness I would like to
> discuss today. I would like to draw your attention to the last number in
> the gtest output lines above.
>
> When adding tests, we also contribute to the time it takes for a complete
> test suite to run. There are multiple ways how we can keep this number
> small (one is, heh, write less tests : ) ). Today I propose to focus on
> reducing duration of individual test cases.
>
> Mesos tests are often build around certain sequences of events, some of
> those have timeouts, some are dependent on other events. Naive test
> implementations sometimes lead to test being blocked by the duration of
> some timeout, pointlessly slowing down the whole suite! A good indicator of
> such a test is that its duration is an integral number of seconds (the
> timeout) plus some delta (actual testing code), for example 3123 ms, 5076
> ms.
>
> Suggestion: If you write a new test, please look at the test duration as
> well, if it seems unreasonably long, investigate what the reasons are and
> how you can make the test faster.
>
> State of the art:
>   * Slave recovery tests are known to be slow, see MESOS-733 [1].
>   * Ben Mahler created an epic to track slow tests more than a year ago
> (MESOS-1757 [2]) and did some work earlier (MESOS-297 [3]).
>   * Dominic Hamon did pretty much what I have done (with a much nicer
> command, too bad I noticed that after generating the list myself) and filed
> MESOS-2059 [4].
>
> To get a list of suspect tests I ran `./bin/mesos-tests.sh 2>/dev/null |
> grep "ms)"` and noted down tests that took more than 1 second to complete.
> To my knowledge, 1s is the shortest timeout we use in default values for
> configurable parameters.
>
> For each test from the list I either created a JIRA ticket, or grouped a
> bunch of seemingly related tickets into an epic (details below). I hijacked
> MESOS-1757 [2] and made it a parent for all newly created epics and
> tickets.
>
> I would like to encourage folks to look at these tickets and work on them
> when they have time and mood. Apart making `make check` faster, I believe
> that most of these tickets are actually a very good way to familiarize
> yourself with the Mesos codebase (hence I marked all tickets as
> `newbie++`), so if you would like to contribute to Mesos but do not know
> where to start — this can be a good choice!
>
> It is clear that some tickets are false positives and there exists a good
> reason why this particular test takes longer than others. In this case a
> comment explaining this reason is a proper resolution for the ticket.
>
> To avoid difficulties with finding a shepherd, I would suggest
> investigating the test first, understanding the reason for the slowness,
> and updating the ticket, so that a potential shepherd can easier estimate
> the amount of time necessary for fixing the issue. Investigating does not
> require a shepherd, and once it is done, all following steps (finding a
> shepherd, submitting a patch, getting it committed) are trivial.
>
> I believe some tests may share the same root cause (for example, they rely
> on the same timeout, which cannot be changed from the test harness). In
> this case all such tests can be fixed by a single change.
>
> Below are the suspect tests.
>   * Examples tests, slow since early days, see MESOS-297 [3]. Filed
> MESOS-4155 [6].
>   * Fetcher cache and fetcher cache http tests, filed MESOS-4156 [7].
>   * Zookeeper tests, some are slow since early days, see MESOS-297 [3].
> Filed MESOS-4157 [8].
>   * Slave recovery tests. Known to be slow, see MESOS-733 [1] and MESOS-297
> [3]. Filed MESOS-4158 [9].
>   * Group tests, filed MESOS-4159 [10].
>   * Recover tests, filed MESOS-4160 [11].
>
>   * SlaveTest.CommandExecutorWithOverride (1311 ms), filed MESOS-4161 [12].
>   * SlaveTest.MetricsSlaveLaunchErrors (1009 ms), filed MESOS-4162 [13].
>   * SlaveTest.HTTPSchedulerSlaveRestart (2307 ms), filed MESOS-4163 [14].
>   * MasterTest.RecoverResources (1018 ms), filed MESOS-4164 [15].
>   * 

Re: Speed up Mesos tests

[Greg Mann]

AlexR, thanks for this great work! :-D It's nice to hear that so many tests
have been added in the past year, and I appreciate the list of tickets to
check out; I'll definitely take one on soon when I have some time.

I'd like to bring up something that both Neil and Joseph mentioned to me
recently, which could be of use when working on these slow test tickets.
Since we have the `process::Clock` class, it's quite easy to control the
clock manually, and doing so can both speed up tests as well as make them
more deterministic/less flaky. While we're working on the above tickets, I
think it would be nice to look for opportunities to alter the tests we're
touching to pause the clock and then advance it explicitly using `pause()`,
`settle()`, and `advance()`, rather than letting it run as usual.

Cheers,
Greg

On Wed, Dec 16, 2015 at 9:01 AM, tommy xiao  wrote:

> +1
>
> 2015-12-16 2:15 GMT+08:00 Alex Rukletsov :
>
> > Folks,
> >
> > I would like to share some facts and thoughts about tests. When I ran
> `make
> > check -j7` on my Mac OS machine the other day, gtest reported the
> following
> > (your numbers may vary depending on the OS you're on and filters you
> use):
> > [==] 882 tests from 117 test cases ran. (298610 ms total)
> >
> > Same command for Mesos 0.21.1, which has been released around a year ago,
> > yields
> > [==] 452 tests from 71 test cases ran. (196398 ms total)
> >
> > We almost doubled the number of tests in 2015. I think this is a great
> > achievement per se, moreover it makes the life of cluster operators,
> > release managers, and Mesos contributors less stressful. I am going to
> have
> > an extra glass of champagne to celebrate this at the upcoming New Year
> Eve
> > : ).
> >
> > There are still some flaky tests left — and there always will be, failure
> > is embedded into progress —, but it is not the flakiness I would like to
> > discuss today. I would like to draw your attention to the last number in
> > the gtest output lines above.
> >
> > When adding tests, we also contribute to the time it takes for a complete
> > test suite to run. There are multiple ways how we can keep this number
> > small (one is, heh, write less tests : ) ). Today I propose to focus on
> > reducing duration of individual test cases.
> >
> > Mesos tests are often build around certain sequences of events, some of
> > those have timeouts, some are dependent on other events. Naive test
> > implementations sometimes lead to test being blocked by the duration of
> > some timeout, pointlessly slowing down the whole suite! A good indicator
> of
> > such a test is that its duration is an integral number of seconds (the
> > timeout) plus some delta (actual testing code), for example 3123 ms, 5076
> > ms.
> >
> > Suggestion: If you write a new test, please look at the test duration as
> > well, if it seems unreasonably long, investigate what the reasons are and
> > how you can make the test faster.
> >
> > State of the art:
> >   * Slave recovery tests are known to be slow, see MESOS-733 [1].
> >   * Ben Mahler created an epic to track slow tests more than a year ago
> > (MESOS-1757 [2]) and did some work earlier (MESOS-297 [3]).
> >   * Dominic Hamon did pretty much what I have done (with a much nicer
> > command, too bad I noticed that after generating the list myself) and
> filed
> > MESOS-2059 [4].
> >
> > To get a list of suspect tests I ran `./bin/mesos-tests.sh 2>/dev/null |
> > grep "ms)"` and noted down tests that took more than 1 second to
> complete.
> > To my knowledge, 1s is the shortest timeout we use in default values for
> > configurable parameters.
> >
> > For each test from the list I either created a JIRA ticket, or grouped a
> > bunch of seemingly related tickets into an epic (details below). I
> hijacked
> > MESOS-1757 [2] and made it a parent for all newly created epics and
> > tickets.
> >
> > I would like to encourage folks to look at these tickets and work on them
> > when they have time and mood. Apart making `make check` faster, I believe
> > that most of these tickets are actually a very good way to familiarize
> > yourself with the Mesos codebase (hence I marked all tickets as
> > `newbie++`), so if you would like to contribute to Mesos but do not know
> > where to start — this can be a good choice!
> >
> > It is clear that some tickets are false positives and there exists a good
> > reason why this particular test takes longer than others. In this case a
> > comment explaining this reason is a proper resolution for the ticket.
> >
> > To avoid difficulties with finding a shepherd, I would suggest
> > investigating the test first, understanding the reason for the slowness,
> > and updating the ticket, so that a potential shepherd can easier estimate
> > the amount of time necessary for fixing the issue. Investigating does not
> > require a shepherd, and once it is done, all following steps (finding a
> > shepherd, submitting a 

Re: Jenkins builds failing for CentOS 7

[Kevin Klues]

I'm assuming this is the script used for building the image ran by jenkins:

support/docker_build.sh

If so, I can verify that this is what is causing the failure.  Running
manually on my local machine:

CONFIGURATION="--verbose --enable-libevent --enable-ssl"
COMPILER="gcc" OS="centos:7" support/docker_build.sh

results in the same failure.

And it stems from the following packages being installed:

 java-1.7.0-openjdk  x86_64 1:1.7.0.91-2.6.2.3.el7   base 207 k
 java-1.7.0-openjdk-develx86_64 1:1.7.0.91-2.6.2.3.el7   base 9.2 M
 java-1.7.0-openjdk-headless x86_64 1:1.7.0.91-2.6.2.3.el7   base  25 M
 java-1.8.0-openjdk  x86_64 1:1.8.0.65-3.b17.el7 base 215 k
 java-1.8.0-openjdk-headless x86_64 1:1.8.0.65-3.b17.el7 base  31 M

we either need to install java-1.8.0-openjdk-devel instead of
java-1.7.0-openjdk-devel, or move things around such that maven is
installed AFTER we install java-1.7.0-openjdk-devel so that its
dependence on java doesn't automatically pull in java-1.8.0-openjdk.

On Wed, Dec 16, 2015 at 1:11 PM, Kevin Klues  wrote:
> Hey all,
>
> 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
>
> I ran into this problem a few days ago while building a vagrant box
> for centos 7.  The problem is summarized in this review request:
>
> https://reviews.apache.org/r/41371/
>
> I'm not familiar with how the docker images for the build are
> launched, but it seems they need to be updated in a manner similar to
> what I propose in the updated getting started guide in the review.
>
> --
> ~Kevin



-- 
~Kevin

Re: Jenkins builds failing for CentOS 7

[Kevin Klues]

I filed a JIRA for this:

https://issues.apache.org/jira/browse/MESOS-4184

On Wed, Dec 16, 2015 at 1:59 PM, Kevin Klues  wrote:
> Verified that both solutions work. That is, either install
> java-1.8.0-openjdk-devel instead of
> java-1.7.0-openjdk-devel, or move things around such that maven is
> installed AFTER we install java-1.7.0-openjdk-devel.
>
> Which one is preferred?  I will put together a patch.
>
> Solution 1:
> --- a/support/docker_build.sh
> +++ b/support/docker_build.sh
> @@ -40,7 +40,7 @@ case $OS in
>  append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
>  append_dockerfile "RUN yum install -y epel-release" # Needed for clang.
>  append_dockerfile "RUN yum install -y clang git maven"
> -append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
> python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> libevent-devel libev-devel"
> +append_dockerfile "RUN yum install -y java-1.8.0-openjdk-devel
> python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> libevent-devel libev-devel"
>
>  # Add an unprivileged user.
>  append_dockerfile "RUN adduser mesos"
>
>
> Solution 2:
> diff --git a/support/docker_build.sh b/support/docker_build.sh
> index c14370d..7058258 100755
> --- a/support/docker_build.sh
> +++ b/support/docker_build.sh
> @@ -39,8 +39,8 @@ case $OS in
>
>  append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
>  append_dockerfile "RUN yum install -y epel-release" # Needed for clang.
> -append_dockerfile "RUN yum install -y clang git maven"
>  append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
> python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> libevent-devel libev-devel"
> +append_dockerfile "RUN yum install -y clang git maven"
>
>  # Add an unprivileged user.
>  append_dockerfile "RUN adduser mesos"
>
> On Wed, Dec 16, 2015 at 1:34 PM, Kevin Klues  wrote:
>> I'm assuming this is the script used for building the image ran by jenkins:
>>
>> support/docker_build.sh
>>
>> If so, I can verify that this is what is causing the failure.  Running
>> manually on my local machine:
>>
>> CONFIGURATION="--verbose --enable-libevent --enable-ssl"
>> COMPILER="gcc" OS="centos:7" support/docker_build.sh
>>
>> results in the same failure.
>>
>> And it stems from the following packages being installed:
>>
>>  java-1.7.0-openjdk  x86_64 1:1.7.0.91-2.6.2.3.el7   base 
>> 207 k
>>  java-1.7.0-openjdk-develx86_64 1:1.7.0.91-2.6.2.3.el7   base 
>> 9.2 M
>>  java-1.7.0-openjdk-headless x86_64 1:1.7.0.91-2.6.2.3.el7   base  
>> 25 M
>>  java-1.8.0-openjdk  x86_64 1:1.8.0.65-3.b17.el7 base 
>> 215 k
>>  java-1.8.0-openjdk-headless x86_64 1:1.8.0.65-3.b17.el7 base  
>> 31 M
>>
>> we either need to install java-1.8.0-openjdk-devel instead of
>> java-1.7.0-openjdk-devel, or move things around such that maven is
>> installed AFTER we install java-1.7.0-openjdk-devel so that its
>> dependence on java doesn't automatically pull in java-1.8.0-openjdk.
>>
>> On Wed, Dec 16, 2015 at 1:11 PM, Kevin Klues  wrote:
>>> Hey all,
>>>
>>> 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
>>>
>>> I ran into this problem a few days ago while building a vagrant box
>>> for centos 7.  The problem is summarized in this review request:
>>>
>>> https://reviews.apache.org/r/41371/
>>>
>>> I'm not familiar with how the docker images for the build are
>>> launched, but it seems they need to be updated in a manner similar to
>>> what I propose in the updated getting started guide in the review.
>>>
>>> --
>>> ~Kevin
>>
>>
>>
>> --
>> ~Kevin
>
>
>
> --
> ~Kevin



-- 
~Kevin

Re: Jenkins builds failing for CentOS 7

[Kevin Klues]

Verified that both solutions work. That is, either install
java-1.8.0-openjdk-devel instead of
java-1.7.0-openjdk-devel, or move things around such that maven is
installed AFTER we install java-1.7.0-openjdk-devel.

Which one is preferred?  I will put together a patch.

Solution 1:
--- a/support/docker_build.sh
+++ b/support/docker_build.sh
@@ -40,7 +40,7 @@ case $OS in
 append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
 append_dockerfile "RUN yum install -y epel-release" # Needed for clang.
 append_dockerfile "RUN yum install -y clang git maven"
-append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
libevent-devel libev-devel"
+append_dockerfile "RUN yum install -y java-1.8.0-openjdk-devel
python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
libevent-devel libev-devel"

 # Add an unprivileged user.
 append_dockerfile "RUN adduser mesos"


Solution 2:
diff --git a/support/docker_build.sh b/support/docker_build.sh
index c14370d..7058258 100755
--- a/support/docker_build.sh
+++ b/support/docker_build.sh
@@ -39,8 +39,8 @@ case $OS in

 append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
 append_dockerfile "RUN yum install -y epel-release" # Needed for clang.
-append_dockerfile "RUN yum install -y clang git maven"
 append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
libevent-devel libev-devel"
+append_dockerfile "RUN yum install -y clang git maven"

 # Add an unprivileged user.
 append_dockerfile "RUN adduser mesos"

On Wed, Dec 16, 2015 at 1:34 PM, Kevin Klues  wrote:
> I'm assuming this is the script used for building the image ran by jenkins:
>
> support/docker_build.sh
>
> If so, I can verify that this is what is causing the failure.  Running
> manually on my local machine:
>
> CONFIGURATION="--verbose --enable-libevent --enable-ssl"
> COMPILER="gcc" OS="centos:7" support/docker_build.sh
>
> results in the same failure.
>
> And it stems from the following packages being installed:
>
>  java-1.7.0-openjdk  x86_64 1:1.7.0.91-2.6.2.3.el7   base 207 
> k
>  java-1.7.0-openjdk-develx86_64 1:1.7.0.91-2.6.2.3.el7   base 9.2 
> M
>  java-1.7.0-openjdk-headless x86_64 1:1.7.0.91-2.6.2.3.el7   base  25 
> M
>  java-1.8.0-openjdk  x86_64 1:1.8.0.65-3.b17.el7 base 215 
> k
>  java-1.8.0-openjdk-headless x86_64 1:1.8.0.65-3.b17.el7 base  31 
> M
>
> we either need to install java-1.8.0-openjdk-devel instead of
> java-1.7.0-openjdk-devel, or move things around such that maven is
> installed AFTER we install java-1.7.0-openjdk-devel so that its
> dependence on java doesn't automatically pull in java-1.8.0-openjdk.
>
> On Wed, Dec 16, 2015 at 1:11 PM, Kevin Klues  wrote:
>> Hey all,
>>
>> 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
>>
>> I ran into this problem a few days ago while building a vagrant box
>> for centos 7.  The problem is summarized in this review request:
>>
>> https://reviews.apache.org/r/41371/
>>
>> I'm not familiar with how the docker images for the build are
>> launched, but it seems they need to be updated in a manner similar to
>> what I propose in the updated getting started guide in the review.
>>
>> --
>> ~Kevin
>
>
>
> --
> ~Kevin



-- 
~Kevin

Re: Jenkins builds failing for CentOS 7

[Michael Park]

I'm +1 on upgrading to 1.8.0. If anyone has experienced issues with running
1.8.0, please let us know!

On Wed, Dec 16, 2015 at 10:00 PM Kevin Klues  wrote:

> I filed a JIRA for this:
>
> https://issues.apache.org/jira/browse/MESOS-4184
>
> On Wed, Dec 16, 2015 at 1:59 PM, Kevin Klues  wrote:
> > Verified that both solutions work. That is, either install
> > java-1.8.0-openjdk-devel instead of
> > java-1.7.0-openjdk-devel, or move things around such that maven is
> > installed AFTER we install java-1.7.0-openjdk-devel.
> >
> > Which one is preferred?  I will put together a patch.
> >
> > Solution 1:
> > --- a/support/docker_build.sh
> > +++ b/support/docker_build.sh
> > @@ -40,7 +40,7 @@ case $OS in
> >  append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
> >  append_dockerfile "RUN yum install -y epel-release" # Needed for
> clang.
> >  append_dockerfile "RUN yum install -y clang git maven"
> > -append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
> > python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> > cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> > libevent-devel libev-devel"
> > +append_dockerfile "RUN yum install -y java-1.8.0-openjdk-devel
> > python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> > cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> > libevent-devel libev-devel"
> >
> >  # Add an unprivileged user.
> >  append_dockerfile "RUN adduser mesos"
> >
> >
> > Solution 2:
> > diff --git a/support/docker_build.sh b/support/docker_build.sh
> > index c14370d..7058258 100755
> > --- a/support/docker_build.sh
> > +++ b/support/docker_build.sh
> > @@ -39,8 +39,8 @@ case $OS in
> >
> >  append_dockerfile "RUN yum groupinstall -y 'Development Tools'"
> >  append_dockerfile "RUN yum install -y epel-release" # Needed for
> clang.
> > -append_dockerfile "RUN yum install -y clang git maven"
> >  append_dockerfile "RUN yum install -y java-1.7.0-openjdk-devel
> > python-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel
> > cyrus-sasl-md5 apr-devel subversion-devel apr-utils-devel
> > libevent-devel libev-devel"
> > +append_dockerfile "RUN yum install -y clang git maven"
> >
> >  # Add an unprivileged user.
> >  append_dockerfile "RUN adduser mesos"
> >
> > On Wed, Dec 16, 2015 at 1:34 PM, Kevin Klues  wrote:
> >> I'm assuming this is the script used for building the image ran by
> jenkins:
> >>
> >> support/docker_build.sh
> >>
> >> If so, I can verify that this is what is causing the failure.  Running
> >> manually on my local machine:
> >>
> >> CONFIGURATION="--verbose --enable-libevent --enable-ssl"
> >> COMPILER="gcc" OS="centos:7" support/docker_build.sh
> >>
> >> results in the same failure.
> >>
> >> And it stems from the following packages being installed:
> >>
> >>  java-1.7.0-openjdk  x86_64 1:1.7.0.91-2.6.2.3.el7
>  base 207 k
> >>  java-1.7.0-openjdk-develx86_64 1:1.7.0.91-2.6.2.3.el7
>  base 9.2 M
> >>  java-1.7.0-openjdk-headless x86_64 1:1.7.0.91-2.6.2.3.el7
>  base  25 M
> >>  java-1.8.0-openjdk  x86_64 1:1.8.0.65-3.b17.el7
>  base 215 k
> >>  java-1.8.0-openjdk-headless x86_64 1:1.8.0.65-3.b17.el7
>  base  31 M
> >>
> >> we either need to install java-1.8.0-openjdk-devel instead of
> >> java-1.7.0-openjdk-devel, or move things around such that maven is
> >> installed AFTER we install java-1.7.0-openjdk-devel so that its
> >> dependence on java doesn't automatically pull in java-1.8.0-openjdk.
> >>
> >> On Wed, Dec 16, 2015 at 1:11 PM, Kevin Klues  wrote:
> >>> Hey all,
> >>>
> >>> 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
> >>>
> >>> I ran into this problem a few days ago while building a vagrant box
> >>> for centos 7.  The problem is summarized in this review request:
> >>>
> >>> https://reviews.apache.org/r/41371/
> >>>
> >>> I'm not familiar with how the docker images for the build are
> >>> launched, but it seems they need to be updated in a manner similar to
> >>> what I propose in the updated getting started guide in the review.
> >>>
> >>> --
> >>> ~Kevin
> >>
> >>
> >>
> >> --
> >> ~Kevin
> >
> >
> >
> > --
> > ~Kevin
>
>
>
> --
> ~Kevin
>

Re: Exclusive resources proposal

[Weitao]

does it make sense considering  DRF which is the real soul of  Mesos, IMO 

发自我的 iPhone

> 在 2015年12月16日，08:39，James Peach  写道：
> 
> 
>> On Dec 15, 2015, at 1:37 PM, Ian Downes  wrote:
>> 
>> Hello everyone,
>> 
>> I'd like to propose adding the concept of exclusivity to resources. An
>> exclusive resource is a) not shared with any other task, b) employs
>> stronger isolation for more predictable performance, and c) is consequently
>> not oversubscribed (if enabled). In contrast to normal resources, exclusive
>> resources have greater resource priority while oversubscribed resources
>> have lower priority.
>> 
>> This is aimed at generally supporting resources like cpu affinity,
>> container IPs, and guaranteed network bandwidth.
>> 
>> Further details are in MESOS-4138
>>  which links to a
>> proposal document. Please take a look and comment if you're interested in
>> this.
> 
> Thanks for sending this around Ian. One question that I had after reading 
> this is who decides whether a Resource is exclusive? Does an agent advertise 
> an exclusive Resource? or does a framework consume an offered Resource in 
> exclusive mode?
> 
> J

Mesos support for ppc64le

[Abhishek Dasgupta]

Hi,

I need to know if powerpc support for mesos is there in version 0.25.0?

Following are the mesos issues which were resolved for 0.22.0. Are those 
changes included in 0.25.0?


https://issues.apache.org/jira/browse/MESOS-3084
https://issues.apache.org/jira/browse/MESOS-3085
https://issues.apache.org/jira/browse/MESOS-2216
https://issues.apache.org/jira/browse/MESOS-3150

Please help.

--
  Regards,

  
---
  Abhishek Dasgupta
  Linux Software Developer - Linux Technology Centre
  IBM Systems Lab,
  IBM India Pvt. Ltd.
  Embassy Golf Link, D Block
  Koramongala - Off Indiranagar Ring Road
  Bangalore - 560 071
  Mobile: +91-8884107981
  
---

Re: Mesos support for ppc64le

[Alex Rukletsov]

Why do you think these tickets are resolved? I see them either in
reviewable, in progress, or open states. Also, review requests seem to have
never been committed. Hence I believe the answer to your second question is
"no". Sorry about that.

On Wed, Dec 16, 2015 at 3:35 PM, Abhishek Dasgupta <
a10gu...@linux.vnet.ibm.com> wrote:

> Hi,
>
> I need to know if powerpc support for mesos is there in version 0.25.0?
>
> Following are the mesos issues which were resolved for 0.22.0. Are those
> changes included in 0.25.0?
>
> https://issues.apache.org/jira/browse/MESOS-3084
> https://issues.apache.org/jira/browse/MESOS-3085
> https://issues.apache.org/jira/browse/MESOS-2216
> https://issues.apache.org/jira/browse/MESOS-3150
>
> Please help.
>
> --
>   Regards,
>
>
> ---
>   Abhishek Dasgupta
>   Linux Software Developer - Linux Technology Centre
>   IBM Systems Lab,
>   IBM India Pvt. Ltd.
>   Embassy Golf Link, D Block
>   Koramongala - Off Indiranagar Ring Road
>   Bangalore - 560 071
>   Mobile: +91-8884107981
>
> ---
>
>

[RESULT][VOTE] Release Apache Mesos 0.26.0 (rc5)

[Till Toenshoff]

Hi friends,

The vote for Mesos 0.26.0 (rc5) has passed with the
following votes.

+1 (Binding)
--
Joris Van Remoortere
Brenden Matthews
Benjamin Mahler
Bernd Mathiske 
Till Toenshoff

+1 (Non-binding)
--
Alexander Rojas

There were no 0 or -1 votes.

Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/0.26.0

It is recommended to use a mirror to download the release:
http://www.apache.org/dyn/closer.cgi

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.26.0

The mesos-0.26.0.jar has been released to:
https://repository.apache.org

The website (http://mesos.apache.org) will be updated shortly to reflect this 
release.

Thanks,

Bernd & Till