Build failed in Jenkins: aurora-packaging-nightly #252

2016-04-04 Thread Apache Jenkins Server 
See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://git-wip-us.apache.org/repos/asf/aurora 
 > # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/aurora
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision f402899bc35b094c41549ca5e6dab80b3b3b4719 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f402899bc35b094c41549ca5e6dab80b3b3b4719
 > git rev-list f402899bc35b094c41549ca5e6dab80b3b3b4719 # timeout=10
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/aurora-packaging
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 97f9c3d0de8dd5fbbb468deb926f578579a4de81 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 97f9c3d0de8dd5fbbb468deb926f578579a4de81
 > git rev-list 97f9c3d0de8dd5fbbb468deb926f578579a4de81 # timeout=10
[aurora-packaging-nightly] $ /bin/bash -xe /tmp/hudson2352873618221909773.sh
+ cd aurora
++ cat .auroraversion
++ date +%Y.%m.%d
+ version=0.13.0-SNAPSHOT.2016.04.05
++ tr '[:upper:]' '[:lower:]'
++ tr -d -
++ echo 0.13.0-SNAPSHOT.2016.04.05
+ version=0.13.0snapshot.2016.04.05
+ git archive --prefix=apache-aurora-0.13.0snapshot.2016.04.05/ -o 
snapshot.tar.gz HEAD
+ cd ../aurora-packaging
+ ./build-artifact.sh ../aurora/snapshot.tar.gz 0.13.0snapshot.2016.04.05
Using docker image aurora-debian-jessie
Sending build context to Docker daemon 6.656 kB
Sending build context to Docker daemon 6.656 kB

Step 1 : FROM debian:jessie-backports
 ---> a2553b9e4849
Step 2 : WORKDIR /aurora
 ---> Using cache
 ---> 3e4917f2788c
Step 3 : ENV HOME /aurora
 ---> Using cache
 ---> e7f83e7616cf
Step 4 : ENV DEBIAN_FRONTEND noninteractive
 ---> Using cache
 ---> 7fd02f4fe391
Step 5 : RUN apt-get update && apt-get -y install   bison   debhelper   
devscripts   dpkg-dev   curl   git   libapr1-dev   libcurl4-openssl-dev   
libkrb5-dev   libsvn-dev   python-all-dev   software-properties-common   
thrift-compiler
 ---> Using cache
 ---> f10c1cdae7c6
Step 6 : RUN apt-get -y -t jessie-backports install openjdk-8-jdk&& 
update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
 ---> Using cache
 ---> 45090a28c491
Step 7 : RUN git clone --depth 1 https://github.com/benley/gradle-packaging   
&& cd gradle-packaging   && apt-get install -y ruby ruby-dev unzip wget   && 
gem install fpm && ./gradle-mkdeb.sh 2.12   && dpkg -i 
gradle-2.12_2.12-2_all.deb   && cd .. && rm -rf gradle-packaging
 ---> Running in 24a091c00d45
Cloning into 'gradle-packaging'...
Reading package lists...
Building dependency tree...
Reading state information...
unzip is already the newest version.
unzip set to manually installed.
The following extra packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby2.1 ruby2.1-dev rubygems-integration
Suggested packages:
  apache2 lighttpd httpd libgmp10-doc libmpfr-dev ri bundler
The following NEW packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby ruby-dev ruby2.1 ruby2.1-dev
  rubygems-integration wget
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.8 MB of archives.
After this operation, 52.0 MB of additional disk space will be used.
Get:1 http://httpredir.debian.org/debian/ jessie/main libgmpxx4ldbl amd64 
2:6.0.0+dfsg-6 [22.1 kB]
Get:2 http://httpredir.debian.org/debian/ jessie/main libicu52 amd64 
52.1-8+deb8u3 [6784 kB]
Get:3 http://httpredir.debian.org/debian/ jessie/main libyaml-0-2 amd64 0.1.6-3 
[50.4 kB]
Get:4 http://httpredir.debian.org/debian/ jessie/main libpsl0 amd64 0.5.1-1 
[41.6 kB]
Get:5 http://httpredir.debian.org/debian/ jessie/main wget amd64 1.16-1 [495 kB]
Get:6

Build failed in Jenkins: aurora-packaging-nightly #251

2016-04-04 Thread Apache Jenkins Server 
See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://git-wip-us.apache.org/repos/asf/aurora 
 > # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/aurora
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision f402899bc35b094c41549ca5e6dab80b3b3b4719 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f402899bc35b094c41549ca5e6dab80b3b3b4719
 > git rev-list f402899bc35b094c41549ca5e6dab80b3b3b4719 # timeout=10
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/aurora-packaging
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 97f9c3d0de8dd5fbbb468deb926f578579a4de81 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 97f9c3d0de8dd5fbbb468deb926f578579a4de81
 > git rev-list 97f9c3d0de8dd5fbbb468deb926f578579a4de81 # timeout=10
[aurora-packaging-nightly] $ /bin/bash -xe /tmp/hudson5882921093266136524.sh
+ cd aurora
++ cat .auroraversion
++ date +%Y.%m.%d
+ version=0.13.0-SNAPSHOT.2016.04.05
++ tr '[:upper:]' '[:lower:]'
++ tr -d -
++ echo 0.13.0-SNAPSHOT.2016.04.05
+ version=0.13.0snapshot.2016.04.05
+ git archive --prefix=apache-aurora-0.13.0snapshot.2016.04.05/ -o 
snapshot.tar.gz HEAD
+ cd ../aurora-packaging
+ ./build-artifact.sh ../aurora/snapshot.tar.gz 0.13.0snapshot.2016.04.05
Using docker image aurora-debian-jessie
Sending build context to Docker daemon 6.656 kB
Sending build context to Docker daemon 6.656 kB

Step 1 : FROM debian:jessie-backports
 ---> a2553b9e4849
Step 2 : WORKDIR /aurora
 ---> Using cache
 ---> 3e4917f2788c
Step 3 : ENV HOME /aurora
 ---> Using cache
 ---> e7f83e7616cf
Step 4 : ENV DEBIAN_FRONTEND noninteractive
 ---> Using cache
 ---> 7fd02f4fe391
Step 5 : RUN apt-get update && apt-get -y install   bison   debhelper   
devscripts   dpkg-dev   curl   git   libapr1-dev   libcurl4-openssl-dev   
libkrb5-dev   libsvn-dev   python-all-dev   software-properties-common   
thrift-compiler
 ---> Using cache
 ---> f10c1cdae7c6
Step 6 : RUN apt-get -y -t jessie-backports install openjdk-8-jdk&& 
update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
 ---> Using cache
 ---> 45090a28c491
Step 7 : RUN git clone --depth 1 https://github.com/benley/gradle-packaging   
&& cd gradle-packaging   && apt-get install -y ruby ruby-dev unzip wget   && 
gem install fpm && ./gradle-mkdeb.sh 2.12   && dpkg -i 
gradle-2.12_2.12-2_all.deb   && cd .. && rm -rf gradle-packaging
 ---> Running in 4a2e0d41c91d
Cloning into 'gradle-packaging'...
Reading package lists...
Building dependency tree...
Reading state information...
unzip is already the newest version.
unzip set to manually installed.
The following extra packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby2.1 ruby2.1-dev rubygems-integration
Suggested packages:
  apache2 lighttpd httpd libgmp10-doc libmpfr-dev ri bundler
The following NEW packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby ruby-dev ruby2.1 ruby2.1-dev
  rubygems-integration wget
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.8 MB of archives.
After this operation, 52.0 MB of additional disk space will be used.
Get:1 http://httpredir.debian.org/debian/ jessie/main libgmpxx4ldbl amd64 
2:6.0.0+dfsg-6 [22.1 kB]
Get:2 http://httpredir.debian.org/debian/ jessie/main libicu52 amd64 
52.1-8+deb8u3 [6784 kB]
Get:3 http://httpredir.debian.org/debian/ jessie/main libpsl0 amd64 0.5.1-1 
[41.6 kB]
Get:4 http://httpredir.debian.org/debian/ jessie/main wget amd64 1.16-1 [495 kB]
Get:5 http://httpredir.debian.org/debian/ jessie/main libgmp-dev amd64 
2:6.0.0+dfsg-6 [621 kB]
Get:6

Build failed in Jenkins: aurora-packaging-nightly #250

2016-04-04 Thread Apache Jenkins Server 
See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://git-wip-us.apache.org/repos/asf/aurora 
 > # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/aurora
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision f402899bc35b094c41549ca5e6dab80b3b3b4719 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f402899bc35b094c41549ca5e6dab80b3b3b4719
 > git rev-list f402899bc35b094c41549ca5e6dab80b3b3b4719 # timeout=10
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/aurora-packaging
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/aurora-packaging 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 97f9c3d0de8dd5fbbb468deb926f578579a4de81 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 97f9c3d0de8dd5fbbb468deb926f578579a4de81
 > git rev-list 97f9c3d0de8dd5fbbb468deb926f578579a4de81 # timeout=10
[aurora-packaging-nightly] $ /bin/bash -xe /tmp/hudson2790740538632110844.sh
+ cd aurora
++ cat .auroraversion
++ date +%Y.%m.%d
+ version=0.13.0-SNAPSHOT.2016.04.05
++ echo 0.13.0-SNAPSHOT.2016.04.05
++ tr '[:upper:]' '[:lower:]'
++ tr -d -
+ version=0.13.0snapshot.2016.04.05
+ git archive --prefix=apache-aurora-0.13.0snapshot.2016.04.05/ -o 
snapshot.tar.gz HEAD
+ cd ../aurora-packaging
+ ./build-artifact.sh ../aurora/snapshot.tar.gz 0.13.0snapshot.2016.04.05
Using docker image aurora-debian-jessie
Sending build context to Docker daemon 6.656 kB
Sending build context to Docker daemon 6.656 kB

Step 1 : FROM debian:jessie-backports
 ---> a2553b9e4849
Step 2 : WORKDIR /aurora
 ---> Using cache
 ---> 3e4917f2788c
Step 3 : ENV HOME /aurora
 ---> Using cache
 ---> e7f83e7616cf
Step 4 : ENV DEBIAN_FRONTEND noninteractive
 ---> Using cache
 ---> 7fd02f4fe391
Step 5 : RUN apt-get update && apt-get -y install   bison   debhelper   
devscripts   dpkg-dev   curl   git   libapr1-dev   libcurl4-openssl-dev   
libkrb5-dev   libsvn-dev   python-all-dev   software-properties-common   
thrift-compiler
 ---> Using cache
 ---> f10c1cdae7c6
Step 6 : RUN apt-get -y -t jessie-backports install openjdk-8-jdk&& 
update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
 ---> Using cache
 ---> 45090a28c491
Step 7 : RUN git clone --depth 1 https://github.com/benley/gradle-packaging   
&& cd gradle-packaging   && apt-get install -y ruby ruby-dev unzip wget   && 
gem install fpm && ./gradle-mkdeb.sh 2.12   && dpkg -i 
gradle-2.12_2.12-2_all.deb   && cd .. && rm -rf gradle-packaging
 ---> Running in 78a9e209fe13
Cloning into 'gradle-packaging'...
Reading package lists...
Building dependency tree...
Reading state information...
unzip is already the newest version.
unzip set to manually installed.
The following extra packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby2.1 ruby2.1-dev rubygems-integration
Suggested packages:
  apache2 lighttpd httpd libgmp10-doc libmpfr-dev ri bundler
The following NEW packages will be installed:
  javascript-common libgmp-dev libgmpxx4ldbl libicu52 libjs-jquery libpsl0
  libruby2.1 libyaml-0-2 ruby ruby-dev ruby2.1 ruby2.1-dev
  rubygems-integration wget
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.8 MB of archives.
After this operation, 52.0 MB of additional disk space will be used.
Get:1 http://httpredir.debian.org/debian/ jessie/main libgmpxx4ldbl amd64 
2:6.0.0+dfsg-6 [22.1 kB]
Get:2 http://httpredir.debian.org/debian/ jessie/main libicu52 amd64 
52.1-8+deb8u3 [6784 kB]
Get:3 http://httpredir.debian.org/debian/ jessie/main libyaml-0-2 amd64 0.1.6-3 
[50.4 kB]
Get:4 http://httpredir.debian.org/debian/ jessie/main libpsl0 amd64 0.5.1-1 
[41.6 kB]
Get:5 http://httpredir.debian.org/debian/ jessie/main wget amd64 1.16-1 [495 kB]
Get:6

Re: Build failed in Jenkins: aurora-packaging-nightly #248

2016-04-04 Thread John Sirois 
On Mon, Apr 4, 2016 at 7:08 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> Changes:
>
> [john.sirois] Upgrade build tools.
>

This was a transient deb fetch error.  Trying a rebuild to make sure
https://reviews.apache.org/r/45662/ is OK.


>
> --
> [...truncated 28890 lines...]
> Get:66 http://httpredir.debian.org/debian/ jessie/main libunistring0
> amd64 0.9.3-5.2+b1 [288 kB]
> Get:67 http://httpredir.debian.org/debian/ jessie/main libgettextpo0
> amd64 0.19.3-2 [138 kB]
> Get:68 http://httpredir.debian.org/debian/ jessie/main libgomp1 amd64
> 4.9.2-10 [37.8 kB]
> Get:69 http://httpredir.debian.org/debian/ jessie/main libitm1 amd64
> 4.9.2-10 [29.2 kB]
> Get:70 http://httpredir.debian.org/debian/ jessie/main liblsan0 amd64
> 4.9.2-10 [92.8 kB]
> Get:71 http://httpredir.debian.org/debian/ jessie/main libmpdec2 amd64
> 2.4.1-1 [85.7 kB]
> Get:72 http://httpredir.debian.org/debian/ jessie/main libmpfr4 amd64
> 3.1.2-2 [527 kB]
> Get:73 http://httpredir.debian.org/debian/ jessie/main libossp-uuid16
> amd64 1.6.2-1.5+b1 [38.0 kB]
> Get:74 http://httpredir.debian.org/debian/ jessie/main libpython2.7 amd64
> 2.7.9-2 [1080 kB]
> Get:75 http://httpredir.debian.org/debian/ jessie/main libc-dev-bin amd64
> 2.19-18+deb8u4 [237 kB]
> Get:76 http://httpredir.debian.org/debian/ jessie/main linux-libc-dev
> amd64 3.16.7-ckt25-1 [1023 kB]
> Get:77 http://httpredir.debian.org/debian/ jessie/main libc6-dev amd64
> 2.19-18+deb8u4 [2002 kB]
> Get:78 http://httpredir.debian.org/debian/ jessie/main libexpat1-dev
> amd64 2.1.0-6+deb8u1 [126 kB]
> Get:79 http://httpredir.debian.org/debian/ jessie/main libpython2.7-dev
> amd64 2.7.9-2 [18.6 MB]
> Get:80 http://httpredir.debian.org/debian/ jessie/main
> libpython3.4-minimal amd64 3.4.2-1 [492 kB]
> Get:81 http://httpredir.debian.org/debian/ jessie/main
> libpython3.4-stdlib amd64 3.4.2-1 [2088 kB]
> Get:82 http://httpredir.debian.org/debian/ jessie/main libquadmath0 amd64
> 4.9.2-10 [129 kB]
> Get:83 http://httpredir.debian.org/debian/ jessie/main libsctp1 amd64
> 1.0.16+dfsg-2 [27.6 kB]
> Get:84 http://httpredir.debian.org/debian/ jessie/main libserf-1-1 amd64
> 1.3.8-1 [52.8 kB]
> Get:85 http://httpredir.debian.org/debian/ jessie/main libsigsegv2 amd64
> 2.10-4+b1 [29.2 kB]
> Get:86 http://httpredir.debian.org/debian/ jessie/main libsvn1 amd64
> 1.8.10-6+deb8u3 [1076 kB]
> Get:87 http://httpredir.debian.org/debian/ jessie/main libtsan0 amd64
> 4.9.2-10 [212 kB]
> Get:88 http://httpredir.debian.org/debian/ jessie/main libubsan0 amd64
> 4.9.2-10 [82.4 kB]
> Get:89 http://httpredir.debian.org/debian/ jessie/main libxau6 amd64
> 1:1.0.8-1 [20.7 kB]
> Get:90 http://httpredir.debian.org/debian/ jessie/main libxdmcp6 amd64
> 1:1.1.1-1+b1 [24.9 kB]
> Get:91 http://httpredir.debian.org/debian/ jessie/main libxcb1 amd64
> 1.10-3+b1 [44.4 kB]
> Get:92 http://httpredir.debian.org/debian/ jessie/main libx11-data all
> 2:1.6.2-3 [126 kB]
> Get:93 http://httpredir.debian.org/debian/ jessie/main libx11-6 amd64
> 2:1.6.2-3 [729 kB]
> Get:94 http://httpredir.debian.org/debian/ jessie/main libxext6 amd64
> 2:1.3.3-1 [52.7 kB]
> Get:95 http://httpredir.debian.org/debian/ jessie/main libxmuu1 amd64
> 2:1.1.2-1 [23.3 kB]
> Get:96 http://httpredir.debian.org/debian/ jessie/main python3.4-minimal
> amd64 3.4.2-1 [1646 kB]
> Get:97 http://httpredir.debian.org/debian/ jessie/main sgml-base all
> 1.26+nmu4 [14.6 kB]
> Get:98 http://httpredir.debian.org/debian/ jessie/main libmpc3 amd64
> 1.0.2-1 [39.3 kB]
> Get:99 http://httpredir.debian.org/debian/ jessie/main apt-utils amd64
> 1.0.9.8.3 [368 kB]
> Get:100 http://httpredir.debian.org/debian/ jessie/main less amd64 458-3
> [124 kB]
> Get:101 http://httpredir.debian.org/debian/ jessie/main manpages all
> 3.74-1 [997 kB]
> Get:102 http://httpredir.debian.org/debian/ jessie/main at amd64 3.1.16-1
> [45.4 kB]
> Get:103 http://httpredir.debian.org/debian/ jessie/main exim4-config all
> 4.84.2-1 [501 kB]
> Get:104 http://httpredir.debian.org/debian/ jessie/main exim4-base amd64
> 4.84.2-1 [1048 kB]
> Get:105 http://httpredir.debian.org/debian/ jessie/main
> exim4-daemon-light amd64 4.84.2-1 [630 kB]
> Get:106 http://httpredir.debian.org/debian/ jessie/main bsd-mailx amd64
> 8.1.2-0.20141216cvs-2 [81.7 kB]
> Get:107 http://httpredir.debian.org/debian/ jessie/main bzip2 amd64
> 1.0.6-7+b3 [46.9 kB]
> Get:108 http://httpredir.debian.org/debian/ jessie/main dbus amd64
> 1.8.20-0+deb8u1 [291 kB]
> Get:109 http://httpredir.debian.org/debian/ jessie/main file amd64
> 1:5.22+15-2+deb8u1 [60.4 kB]
> Get:110 http://httpredir.debian.org/debian/ jessie/main gettext-base
> amd64 0.19.3-2 [121 kB]
> Get:111 http://httpredir.debian.org/debian/ jessie/main krb5-locales all
> 1.12.1+dfsg-19+deb8u2 [2649 kB]
> Get:112 http://httpredir.debian.org/debian/ jessie/main m4 amd64 1.4.17-4
> [254 kB]
> Get:113 http://httpredir.debian.org/debian/

Build failed in Jenkins: aurora-packaging-nightly #248

2016-04-04 Thread Apache Jenkins Server 
See 

Changes:

[john.sirois] Upgrade build tools.

--
[...truncated 28890 lines...]
Get:66 http://httpredir.debian.org/debian/ jessie/main libunistring0 amd64 
0.9.3-5.2+b1 [288 kB]
Get:67 http://httpredir.debian.org/debian/ jessie/main libgettextpo0 amd64 
0.19.3-2 [138 kB]
Get:68 http://httpredir.debian.org/debian/ jessie/main libgomp1 amd64 4.9.2-10 
[37.8 kB]
Get:69 http://httpredir.debian.org/debian/ jessie/main libitm1 amd64 4.9.2-10 
[29.2 kB]
Get:70 http://httpredir.debian.org/debian/ jessie/main liblsan0 amd64 4.9.2-10 
[92.8 kB]
Get:71 http://httpredir.debian.org/debian/ jessie/main libmpdec2 amd64 2.4.1-1 
[85.7 kB]
Get:72 http://httpredir.debian.org/debian/ jessie/main libmpfr4 amd64 3.1.2-2 
[527 kB]
Get:73 http://httpredir.debian.org/debian/ jessie/main libossp-uuid16 amd64 
1.6.2-1.5+b1 [38.0 kB]
Get:74 http://httpredir.debian.org/debian/ jessie/main libpython2.7 amd64 
2.7.9-2 [1080 kB]
Get:75 http://httpredir.debian.org/debian/ jessie/main libc-dev-bin amd64 
2.19-18+deb8u4 [237 kB]
Get:76 http://httpredir.debian.org/debian/ jessie/main linux-libc-dev amd64 
3.16.7-ckt25-1 [1023 kB]
Get:77 http://httpredir.debian.org/debian/ jessie/main libc6-dev amd64 
2.19-18+deb8u4 [2002 kB]
Get:78 http://httpredir.debian.org/debian/ jessie/main libexpat1-dev amd64 
2.1.0-6+deb8u1 [126 kB]
Get:79 http://httpredir.debian.org/debian/ jessie/main libpython2.7-dev amd64 
2.7.9-2 [18.6 MB]
Get:80 http://httpredir.debian.org/debian/ jessie/main libpython3.4-minimal 
amd64 3.4.2-1 [492 kB]
Get:81 http://httpredir.debian.org/debian/ jessie/main libpython3.4-stdlib 
amd64 3.4.2-1 [2088 kB]
Get:82 http://httpredir.debian.org/debian/ jessie/main libquadmath0 amd64 
4.9.2-10 [129 kB]
Get:83 http://httpredir.debian.org/debian/ jessie/main libsctp1 amd64 
1.0.16+dfsg-2 [27.6 kB]
Get:84 http://httpredir.debian.org/debian/ jessie/main libserf-1-1 amd64 
1.3.8-1 [52.8 kB]
Get:85 http://httpredir.debian.org/debian/ jessie/main libsigsegv2 amd64 
2.10-4+b1 [29.2 kB]
Get:86 http://httpredir.debian.org/debian/ jessie/main libsvn1 amd64 
1.8.10-6+deb8u3 [1076 kB]
Get:87 http://httpredir.debian.org/debian/ jessie/main libtsan0 amd64 4.9.2-10 
[212 kB]
Get:88 http://httpredir.debian.org/debian/ jessie/main libubsan0 amd64 4.9.2-10 
[82.4 kB]
Get:89 http://httpredir.debian.org/debian/ jessie/main libxau6 amd64 1:1.0.8-1 
[20.7 kB]
Get:90 http://httpredir.debian.org/debian/ jessie/main libxdmcp6 amd64 
1:1.1.1-1+b1 [24.9 kB]
Get:91 http://httpredir.debian.org/debian/ jessie/main libxcb1 amd64 1.10-3+b1 
[44.4 kB]
Get:92 http://httpredir.debian.org/debian/ jessie/main libx11-data all 
2:1.6.2-3 [126 kB]
Get:93 http://httpredir.debian.org/debian/ jessie/main libx11-6 amd64 2:1.6.2-3 
[729 kB]
Get:94 http://httpredir.debian.org/debian/ jessie/main libxext6 amd64 2:1.3.3-1 
[52.7 kB]
Get:95 http://httpredir.debian.org/debian/ jessie/main libxmuu1 amd64 2:1.1.2-1 
[23.3 kB]
Get:96 http://httpredir.debian.org/debian/ jessie/main python3.4-minimal amd64 
3.4.2-1 [1646 kB]
Get:97 http://httpredir.debian.org/debian/ jessie/main sgml-base all 1.26+nmu4 
[14.6 kB]
Get:98 http://httpredir.debian.org/debian/ jessie/main libmpc3 amd64 1.0.2-1 
[39.3 kB]
Get:99 http://httpredir.debian.org/debian/ jessie/main apt-utils amd64 
1.0.9.8.3 [368 kB]
Get:100 http://httpredir.debian.org/debian/ jessie/main less amd64 458-3 [124 
kB]
Get:101 http://httpredir.debian.org/debian/ jessie/main manpages all 3.74-1 
[997 kB]
Get:102 http://httpredir.debian.org/debian/ jessie/main at amd64 3.1.16-1 [45.4 
kB]
Get:103 http://httpredir.debian.org/debian/ jessie/main exim4-config all 
4.84.2-1 [501 kB]
Get:104 http://httpredir.debian.org/debian/ jessie/main exim4-base amd64 
4.84.2-1 [1048 kB]
Get:105 http://httpredir.debian.org/debian/ jessie/main exim4-daemon-light 
amd64 4.84.2-1 [630 kB]
Get:106 http://httpredir.debian.org/debian/ jessie/main bsd-mailx amd64 
8.1.2-0.20141216cvs-2 [81.7 kB]
Get:107 http://httpredir.debian.org/debian/ jessie/main bzip2 amd64 1.0.6-7+b3 
[46.9 kB]
Get:108 http://httpredir.debian.org/debian/ jessie/main dbus amd64 
1.8.20-0+deb8u1 [291 kB]
Get:109 http://httpredir.debian.org/debian/ jessie/main file amd64 
1:5.22+15-2+deb8u1 [60.4 kB]
Get:110 http://httpredir.debian.org/debian/ jessie/main gettext-base amd64 
0.19.3-2 [121 kB]
Get:111 http://httpredir.debian.org/debian/ jessie/main krb5-locales all 
1.12.1+dfsg-19+deb8u2 [2649 kB]
Get:112 http://httpredir.debian.org/debian/ jessie/main m4 amd64 1.4.17-4 [254 
kB]
Get:113 http://httpredir.debian.org/debian/ jessie/main openssh-client amd64 
1:6.7p1-5+deb8u1 [691 kB]
Get:114 http://httpredir.debian.org/debian/ jessie/main patch amd64 2.7.5-1 
[109 kB]
Get:115 http://httpredir.debian.org/debian/ jessie/main ucf all 3.0030 [69.7 kB]
Get:116 http://httpredir.debian.org/debian/ jessie/main xz-utils amd64 
5.1.1alpha+20120614-2+b3 [221 kB]
Get:117

Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner 
>
> There is no process to host the observer UI when a task terminates.


Aha, i didn't realize that was in reference to Steve's comment "have the
executor itself host the observer web UI".
I agree, that approach is encumbered for terminal tasks.

On Mon, Apr 4, 2016 at 5:10 PM, Maxim Khutornenko  wrote:

> Sorry, I should have tried harder explaining myself. There is no
> process to host the observer UI when a task terminates. We still want
> (and arguably more so) to look at terminal task details but since
> there is no process left to host the http server, there is no way to
> access that data in the current way of things.
>
> On Mon, Apr 4, 2016 at 3:54 PM, Bill Farner  wrote:
> >>
> >> It falls apart for terminal tasks when executor process is not running
> >> anymore.
> >
> >
> > This sounds important...can you recall what would not work in that
> > scenario?  I figured it would work ~identically because the observer
> > follows the lifecycle of the task sandbox directory.
> >
> > On Mon, Apr 4, 2016 at 2:43 PM, Maxim Khutornenko 
> wrote:
> >
> >> I think we've discussed this option before. It falls apart for
> >> terminal tasks when executor process is not running anymore.
> >>
> >> One of the possible ways forward could be extending Mesos UI to
> >> opportunistically consume task data periodically dumped by an executor
> >> into a json file. That could cover the functionality gap created by
> >> killing the observer and let other frameworks customize their task
> >> views in a standard and pluggable way.
> >>
> >> On Mon, Apr 4, 2016 at 2:31 PM, Steve Niemitz 
> wrote:
> >> > It seems like the easiest path forward would be to have the executor
> >> itself
> >> > host the observer web UI, if the HTTP port for the UI were configured
> as
> >> > just another port on the task, the aurora UI could just link to /mname
> >> for
> >> > that instance.
> >> >
> >> > I think the overall "what is running on this machine" view the
> observer
> >> > displays (if you go to it without a task ID) is much less useful and
> >> could
> >> > probably be removed without much sadness.
> >> >
> >> > On Mon, Apr 4, 2016 at 5:23 PM, Bill Farner 
> wrote:
> >> >
> >> >> >
> >> >> > why don't we revisit the problem from the other direction and see
> if
> >> we
> >> >> > can remove checkpoints?
> >> >>
> >> >>
> >> >> Simplicity, again :-)  If it turns out we don't need the observer
> >> anyhow,
> >> >> it saves a lot of time.  I'm just poking at different parts to make
> >> sure we
> >> >> can still justify their weight.
> >> >>
> >> >> On Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji 
> wrote:
> >> >>
> >> >> > On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner 
> >> wrote:
> >> >> >
> >> >> > > We clearly have different experiences - i've never really
> benefited
> >> >> from
> >> >> > > viewing the process graph, as most jobs have very simple
> sequences
> >> that
> >> >> > > could be easily explained by a text file in the sandbox.  On the
> >> >> > contrary,
> >> >> > > i've encountered people confused by the process graph, the
> observer,
> >> >> and
> >> >> > > sandbox browsing...so i must respectfully disagree that it is
> >> >> universally
> >> >> > > appreciated.
> >> >> > >
> >> >> > > What i'm trying to achieve is simplicity.  The observer is an
> extra
> >> >> > moving
> >> >> > > part, and another thing for operators to understand and maintain.
> >> It
> >> >> > also
> >> >> > > couples Aurora to one relatively specific way of running tasks,
> >> which
> >> >> > makes
> >> >> > > it difficult to open new use cases like Docker tasks.  Removing
> the
> >> >> > > observer starts to pull on a thread of complexity that i don't
> think
> >> >> > Aurora
> >> >> > > benefits much from, for example state checkpointing by the
> executor.
> >> >> > >
> >> >> > > My goal is not to apply pressure, but to perform a gut check.  If
> >> the
> >> >> > > answer is "No", that's fine.
> >> >> > >
> >> >> >
> >> >> >
> >> >> > Bill,
> >> >> >
> >> >> > I think you are pulling on the right thread here but I think
> >> revisiting
> >> >> the
> >> >> > observer is the wrong way of approaching the problem. I also agree
> >> that
> >> >> > Aurora doesn't benefit much from state checkpointing by the
> executor
> >> and
> >> >> > the observer is an extension of that since it provides a read only
> >> human
> >> >> > friendly view of the data in the checkpoints. However, instead of
> >> >> removing
> >> >> > the observer (and degrading the UX around accessing the data in the
> >> >> > checkpoints), why don't we revisit the problem from the other
> >> direction
> >> >> and
> >> >> > see if we can remove checkpoints?
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Zameer Manji
> >> >> >
> >> >>
> >>
>

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko 
Sorry, I should have tried harder explaining myself. There is no
process to host the observer UI when a task terminates. We still want
(and arguably more so) to look at terminal task details but since
there is no process left to host the http server, there is no way to
access that data in the current way of things.

On Mon, Apr 4, 2016 at 3:54 PM, Bill Farner  wrote:
>>
>> It falls apart for terminal tasks when executor process is not running
>> anymore.
>
>
> This sounds important...can you recall what would not work in that
> scenario?  I figured it would work ~identically because the observer
> follows the lifecycle of the task sandbox directory.
>
> On Mon, Apr 4, 2016 at 2:43 PM, Maxim Khutornenko  wrote:
>
>> I think we've discussed this option before. It falls apart for
>> terminal tasks when executor process is not running anymore.
>>
>> One of the possible ways forward could be extending Mesos UI to
>> opportunistically consume task data periodically dumped by an executor
>> into a json file. That could cover the functionality gap created by
>> killing the observer and let other frameworks customize their task
>> views in a standard and pluggable way.
>>
>> On Mon, Apr 4, 2016 at 2:31 PM, Steve Niemitz  wrote:
>> > It seems like the easiest path forward would be to have the executor
>> itself
>> > host the observer web UI, if the HTTP port for the UI were configured as
>> > just another port on the task, the aurora UI could just link to /mname
>> for
>> > that instance.
>> >
>> > I think the overall "what is running on this machine" view the observer
>> > displays (if you go to it without a task ID) is much less useful and
>> could
>> > probably be removed without much sadness.
>> >
>> > On Mon, Apr 4, 2016 at 5:23 PM, Bill Farner  wrote:
>> >
>> >> >
>> >> > why don't we revisit the problem from the other direction and see if
>> we
>> >> > can remove checkpoints?
>> >>
>> >>
>> >> Simplicity, again :-)  If it turns out we don't need the observer
>> anyhow,
>> >> it saves a lot of time.  I'm just poking at different parts to make
>> sure we
>> >> can still justify their weight.
>> >>
>> >> On Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji  wrote:
>> >>
>> >> > On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner 
>> wrote:
>> >> >
>> >> > > We clearly have different experiences - i've never really benefited
>> >> from
>> >> > > viewing the process graph, as most jobs have very simple sequences
>> that
>> >> > > could be easily explained by a text file in the sandbox.  On the
>> >> > contrary,
>> >> > > i've encountered people confused by the process graph, the observer,
>> >> and
>> >> > > sandbox browsing...so i must respectfully disagree that it is
>> >> universally
>> >> > > appreciated.
>> >> > >
>> >> > > What i'm trying to achieve is simplicity.  The observer is an extra
>> >> > moving
>> >> > > part, and another thing for operators to understand and maintain.
>> It
>> >> > also
>> >> > > couples Aurora to one relatively specific way of running tasks,
>> which
>> >> > makes
>> >> > > it difficult to open new use cases like Docker tasks.  Removing the
>> >> > > observer starts to pull on a thread of complexity that i don't think
>> >> > Aurora
>> >> > > benefits much from, for example state checkpointing by the executor.
>> >> > >
>> >> > > My goal is not to apply pressure, but to perform a gut check.  If
>> the
>> >> > > answer is "No", that's fine.
>> >> > >
>> >> >
>> >> >
>> >> > Bill,
>> >> >
>> >> > I think you are pulling on the right thread here but I think
>> revisiting
>> >> the
>> >> > observer is the wrong way of approaching the problem. I also agree
>> that
>> >> > Aurora doesn't benefit much from state checkpointing by the executor
>> and
>> >> > the observer is an extension of that since it provides a read only
>> human
>> >> > friendly view of the data in the checkpoints. However, instead of
>> >> removing
>> >> > the observer (and degrading the UX around accessing the data in the
>> >> > checkpoints), why don't we revisit the problem from the other
>> direction
>> >> and
>> >> > see if we can remove checkpoints?
>> >> >
>> >> >
>> >> > --
>> >> > Zameer Manji
>> >> >
>> >>
>>

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko 
I think we've discussed this option before. It falls apart for
terminal tasks when executor process is not running anymore.

One of the possible ways forward could be extending Mesos UI to
opportunistically consume task data periodically dumped by an executor
into a json file. That could cover the functionality gap created by
killing the observer and let other frameworks customize their task
views in a standard and pluggable way.

On Mon, Apr 4, 2016 at 2:31 PM, Steve Niemitz  wrote:
> It seems like the easiest path forward would be to have the executor itself
> host the observer web UI, if the HTTP port for the UI were configured as
> just another port on the task, the aurora UI could just link to /mname for
> that instance.
>
> I think the overall "what is running on this machine" view the observer
> displays (if you go to it without a task ID) is much less useful and could
> probably be removed without much sadness.
>
> On Mon, Apr 4, 2016 at 5:23 PM, Bill Farner  wrote:
>
>> >
>> > why don't we revisit the problem from the other direction and see if we
>> > can remove checkpoints?
>>
>>
>> Simplicity, again :-)  If it turns out we don't need the observer anyhow,
>> it saves a lot of time.  I'm just poking at different parts to make sure we
>> can still justify their weight.
>>
>> On Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji  wrote:
>>
>> > On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner  wrote:
>> >
>> > > We clearly have different experiences - i've never really benefited
>> from
>> > > viewing the process graph, as most jobs have very simple sequences that
>> > > could be easily explained by a text file in the sandbox.  On the
>> > contrary,
>> > > i've encountered people confused by the process graph, the observer,
>> and
>> > > sandbox browsing...so i must respectfully disagree that it is
>> universally
>> > > appreciated.
>> > >
>> > > What i'm trying to achieve is simplicity.  The observer is an extra
>> > moving
>> > > part, and another thing for operators to understand and maintain.  It
>> > also
>> > > couples Aurora to one relatively specific way of running tasks, which
>> > makes
>> > > it difficult to open new use cases like Docker tasks.  Removing the
>> > > observer starts to pull on a thread of complexity that i don't think
>> > Aurora
>> > > benefits much from, for example state checkpointing by the executor.
>> > >
>> > > My goal is not to apply pressure, but to perform a gut check.  If the
>> > > answer is "No", that's fine.
>> > >
>> >
>> >
>> > Bill,
>> >
>> > I think you are pulling on the right thread here but I think revisiting
>> the
>> > observer is the wrong way of approaching the problem. I also agree that
>> > Aurora doesn't benefit much from state checkpointing by the executor and
>> > the observer is an extension of that since it provides a read only human
>> > friendly view of the data in the checkpoints. However, instead of
>> removing
>> > the observer (and degrading the UX around accessing the data in the
>> > checkpoints), why don't we revisit the problem from the other direction
>> and
>> > see if we can remove checkpoints?
>> >
>> >
>> > --
>> > Zameer Manji
>> >
>>

Re: Are we ready to remove the observer?

2016-04-04 Thread Steve Niemitz 
It seems like the easiest path forward would be to have the executor itself
host the observer web UI, if the HTTP port for the UI were configured as
just another port on the task, the aurora UI could just link to /mname for
that instance.

I think the overall "what is running on this machine" view the observer
displays (if you go to it without a task ID) is much less useful and could
probably be removed without much sadness.

On Mon, Apr 4, 2016 at 5:23 PM, Bill Farner  wrote:

> >
> > why don't we revisit the problem from the other direction and see if we
> > can remove checkpoints?
>
>
> Simplicity, again :-)  If it turns out we don't need the observer anyhow,
> it saves a lot of time.  I'm just poking at different parts to make sure we
> can still justify their weight.
>
> On Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji  wrote:
>
> > On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner  wrote:
> >
> > > We clearly have different experiences - i've never really benefited
> from
> > > viewing the process graph, as most jobs have very simple sequences that
> > > could be easily explained by a text file in the sandbox.  On the
> > contrary,
> > > i've encountered people confused by the process graph, the observer,
> and
> > > sandbox browsing...so i must respectfully disagree that it is
> universally
> > > appreciated.
> > >
> > > What i'm trying to achieve is simplicity.  The observer is an extra
> > moving
> > > part, and another thing for operators to understand and maintain.  It
> > also
> > > couples Aurora to one relatively specific way of running tasks, which
> > makes
> > > it difficult to open new use cases like Docker tasks.  Removing the
> > > observer starts to pull on a thread of complexity that i don't think
> > Aurora
> > > benefits much from, for example state checkpointing by the executor.
> > >
> > > My goal is not to apply pressure, but to perform a gut check.  If the
> > > answer is "No", that's fine.
> > >
> >
> >
> > Bill,
> >
> > I think you are pulling on the right thread here but I think revisiting
> the
> > observer is the wrong way of approaching the problem. I also agree that
> > Aurora doesn't benefit much from state checkpointing by the executor and
> > the observer is an extension of that since it provides a read only human
> > friendly view of the data in the checkpoints. However, instead of
> removing
> > the observer (and degrading the UX around accessing the data in the
> > checkpoints), why don't we revisit the problem from the other direction
> and
> > see if we can remove checkpoints?
> >
> >
> > --
> > Zameer Manji
> >
>

Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner 
>
> why don't we revisit the problem from the other direction and see if we
> can remove checkpoints?


Simplicity, again :-)  If it turns out we don't need the observer anyhow,
it saves a lot of time.  I'm just poking at different parts to make sure we
can still justify their weight.

On Mon, Apr 4, 2016 at 1:54 PM, Zameer Manji  wrote:

> On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner  wrote:
>
> > We clearly have different experiences - i've never really benefited from
> > viewing the process graph, as most jobs have very simple sequences that
> > could be easily explained by a text file in the sandbox.  On the
> contrary,
> > i've encountered people confused by the process graph, the observer, and
> > sandbox browsing...so i must respectfully disagree that it is universally
> > appreciated.
> >
> > What i'm trying to achieve is simplicity.  The observer is an extra
> moving
> > part, and another thing for operators to understand and maintain.  It
> also
> > couples Aurora to one relatively specific way of running tasks, which
> makes
> > it difficult to open new use cases like Docker tasks.  Removing the
> > observer starts to pull on a thread of complexity that i don't think
> Aurora
> > benefits much from, for example state checkpointing by the executor.
> >
> > My goal is not to apply pressure, but to perform a gut check.  If the
> > answer is "No", that's fine.
> >
>
>
> Bill,
>
> I think you are pulling on the right thread here but I think revisiting the
> observer is the wrong way of approaching the problem. I also agree that
> Aurora doesn't benefit much from state checkpointing by the executor and
> the observer is an extension of that since it provides a read only human
> friendly view of the data in the checkpoints. However, instead of removing
> the observer (and degrading the UX around accessing the data in the
> checkpoints), why don't we revisit the problem from the other direction and
> see if we can remove checkpoints?
>
>
> --
> Zameer Manji
>

Re: [DISCUSS]: 0.13.0 release candidate

2016-04-04 Thread Maxim Khutornenko 
+1

On Mon, Apr 4, 2016 at 2:10 PM, Zameer Manji  wrote:
> +1
>
> On Mon, Apr 4, 2016 at 12:27 PM, Bill Farner  wrote:
>
>> +1, fire away
>>
>> On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell  wrote:
>>
>> > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it
>> > looks like we are about ready to cut the 0.13.0 release candidate and
>> start
>> > a vote. I wanted to open the floor up for any last minute requests or
>> > patches people would like to see make it in before we finalize and cut
>> the
>> > release candidate. Currently planning on cutting the release candidate
>> this
>> > Wednesday, April 6th, pending no blockers coming out of this discussion
>> > thread. Thoughts, objections?
>> >
>> > -Jake
>> >
>> >
>> > [1]: https://issues.apache.org/jira/browse/AURORA-1584
>> >
>>
>> --
>> Zameer Manji
>>
>>

Re: [DISCUSS]: 0.13.0 release candidate

2016-04-04 Thread Zameer Manji 
+1

On Mon, Apr 4, 2016 at 12:27 PM, Bill Farner  wrote:

> +1, fire away
>
> On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell  wrote:
>
> > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it
> > looks like we are about ready to cut the 0.13.0 release candidate and
> start
> > a vote. I wanted to open the floor up for any last minute requests or
> > patches people would like to see make it in before we finalize and cut
> the
> > release candidate. Currently planning on cutting the release candidate
> this
> > Wednesday, April 6th, pending no blockers coming out of this discussion
> > thread. Thoughts, objections?
> >
> > -Jake
> >
> >
> > [1]: https://issues.apache.org/jira/browse/AURORA-1584
> >
>
> --
> Zameer Manji
>
>

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko 
I am with Josh on this one. Thermos Observer UI (and especially its
process graph) is one of the features universally appreciated by our
customers. I am all for deprecating the Observer but only in way that
retains parity with the existing functionality and hopefully enhances
it. What are we trying to achieve here that would justify losing some
of our feature set?

On Mon, Apr 4, 2016 at 12:42 PM, Erb, Stephan
 wrote:
> Have you recently looked at the Mesos UI, Joshua? It offers sandbox browsing 
> similar to the chroot link of Thermos. So at least you don't have to do SSH 
> into any box. We could link to that Mesos UI instead of the Thermos one, and 
> Mesos could then serve a nice index.html that contains the content that was 
> formerly served by Thermos.
>
> When dropping Thermos and relying on Mesos instead, we could profit from the 
> recent addition such as authentication.
>
>
> 
> From: Joshua Cohen 
> Sent: Monday, April 4, 2016 18:42
> To: dev@aurora.apache.org
> Subject: Re: Are we ready to remove the observer?
>
> If you're suggesting just going to the task directory and pulling them out
> of the executor logs. Yes, I could ssh into the host the task is running on
> and grep the task directory out of the mesos agent logs and then trawl the
> logs (or cat task.json), but that's much more effort than going to the
> observer's task UI (i.e. it'd take a minute, rather than a few seconds).
> I'd also posit that it's much easier for new Aurora operators to come to
> grips with the process tree via the UI rather than a JSON blob.
>
> If you're suggesting something else (i.e. new UI to expose these separate
> from the Observer), I'm fine with that, that's what I was implying above
> would be necessary before I think we could retire the Observer.
>
> A counter question: do people feel that updating/deploying the Observer is
> a major obstacle? I know we've got the process well automated, so it's
> relatively painless. I'd love to replace the Observer with something
> better, but I don't feel like it's a major drag on our productivity as it
> exists today to warrant killing it off entirely. My opinion may be colored
> by the deploy automation we have in place though!
>
> On Mon, Apr 4, 2016 at 9:32 AM, Bill Farner  wrote:
>
>> >
>> > 2) Providing an easy view of a process's command-line
>> > 3) Providing a holistic view of the task config
>>
>>
>> Just to check my understanding - these could be trivially handled in
>> text/log format, right?
>>
>> On Mon, Apr 4, 2016 at 9:30 AM, Joshua Cohen  wrote:
>>
>> > I'm -1 on this until we have an actual replacement for the Observer. I
>> > think that the observer provides significant value outside of just
>> sandbox
>> > browsing:
>> >
>> > 1) Exporting task-level statistics.
>> > 2) Providing an easy view of a process's command-line
>> > 3) Providing a holistic view of the task config
>> > 4) Real time utilization stats
>> >
>> > As a cluster operator, I use all of these features on a daily basis
>> > (especially when I'm on call) in addition to sandbox browsing, so I don't
>> > think that these uses cases are that rare.
>> >
>> > On Fri, Apr 1, 2016 at 6:55 AM, Steve Niemitz 
>> wrote:
>> >
>> > > The per-process stats have never been very useful to us (since they
>> don't
>> > > work for docker), however, even being able to see the processes that
>> are
>> > > running, how many times they've restarted, when they launched, etc is
>> > > invaluable.
>> > >
>> > > I think there would be big pushback from users if they were to lose the
>> > > functionality it provided currently (beyond log viewing).
>> > >
>> > > On Fri, Apr 1, 2016 at 6:58 AM, Erb, Stephan <
>> > stephan@blue-yonder.com>
>> > > wrote:
>> > >
>> > > > From an operator and Aurora developer perspective, it would be really
>> > > > great to get rid of the thermos observer quickly.
>> > > >
>> > > > However, from a user perspective the usability gap between observer
>> and
>> > > > plain Mesos sandbox browsing is quite large right now. I agree with
>> > > > Benjamin here that it would probably work if we generate html pages
>> > ready
>> > > > for user consumption.
>> > > >
>> > > > These are the relevant tickets in our tracker:
>> > > > * https://issues.apache.org/jira/browse/AURORA-725
>> > > > * https://issues.apache.org/jira/browse/AURORA-777
>> > > >
>> > > > 
>> > > > From: ben...@gmail.com 
>> > > > Sent: Friday, April 1, 2016 02:35
>> > > > To: dev@aurora.apache.org
>> > > > Subject: Re: Are we ready to remove the observer?
>> > > >
>> > > > Is there any chance we can keep the per-process cpu and ram
>> utilization
>> > > > stats?  That's one of the coolest things about aurora, imo.  The
>> > executor
>> > > > is already writing those checkpoints inside the mesos sandbox (I
>> >

Re: [DISCUSS]: 0.13.0 release candidate

2016-04-04 Thread Bill Farner 
+1, fire away

On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell  wrote:

> Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it
> looks like we are about ready to cut the 0.13.0 release candidate and start
> a vote. I wanted to open the floor up for any last minute requests or
> patches people would like to see make it in before we finalize and cut the
> release candidate. Currently planning on cutting the release candidate this
> Wednesday, April 6th, pending no blockers coming out of this discussion
> thread. Thoughts, objections?
>
> -Jake
>
>
> [1]: https://issues.apache.org/jira/browse/AURORA-1584
>

[DISCUSS]: 0.13.0 release candidate

2016-04-04 Thread Jake Farrell 
Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it
looks like we are about ready to cut the 0.13.0 release candidate and start
a vote. I wanted to open the floor up for any last minute requests or
patches people would like to see make it in before we finalize and cut the
release candidate. Currently planning on cutting the release candidate this
Wednesday, April 6th, pending no blockers coming out of this discussion
thread. Thoughts, objections?

-Jake


[1]: https://issues.apache.org/jira/browse/AURORA-1584

Jenkins build is back to normal : Aurora #1447

2016-04-04 Thread Apache Jenkins Server 
See

Re: Are we ready to remove the observer?

2016-04-04 Thread Joshua Cohen 
If you're suggesting just going to the task directory and pulling them out
of the executor logs. Yes, I could ssh into the host the task is running on
and grep the task directory out of the mesos agent logs and then trawl the
logs (or cat task.json), but that's much more effort than going to the
observer's task UI (i.e. it'd take a minute, rather than a few seconds).
I'd also posit that it's much easier for new Aurora operators to come to
grips with the process tree via the UI rather than a JSON blob.

If you're suggesting something else (i.e. new UI to expose these separate
from the Observer), I'm fine with that, that's what I was implying above
would be necessary before I think we could retire the Observer.

A counter question: do people feel that updating/deploying the Observer is
a major obstacle? I know we've got the process well automated, so it's
relatively painless. I'd love to replace the Observer with something
better, but I don't feel like it's a major drag on our productivity as it
exists today to warrant killing it off entirely. My opinion may be colored
by the deploy automation we have in place though!

On Mon, Apr 4, 2016 at 9:32 AM, Bill Farner  wrote:

> >
> > 2) Providing an easy view of a process's command-line
> > 3) Providing a holistic view of the task config
>
>
> Just to check my understanding - these could be trivially handled in
> text/log format, right?
>
> On Mon, Apr 4, 2016 at 9:30 AM, Joshua Cohen  wrote:
>
> > I'm -1 on this until we have an actual replacement for the Observer. I
> > think that the observer provides significant value outside of just
> sandbox
> > browsing:
> >
> > 1) Exporting task-level statistics.
> > 2) Providing an easy view of a process's command-line
> > 3) Providing a holistic view of the task config
> > 4) Real time utilization stats
> >
> > As a cluster operator, I use all of these features on a daily basis
> > (especially when I'm on call) in addition to sandbox browsing, so I don't
> > think that these uses cases are that rare.
> >
> > On Fri, Apr 1, 2016 at 6:55 AM, Steve Niemitz 
> wrote:
> >
> > > The per-process stats have never been very useful to us (since they
> don't
> > > work for docker), however, even being able to see the processes that
> are
> > > running, how many times they've restarted, when they launched, etc is
> > > invaluable.
> > >
> > > I think there would be big pushback from users if they were to lose the
> > > functionality it provided currently (beyond log viewing).
> > >
> > > On Fri, Apr 1, 2016 at 6:58 AM, Erb, Stephan <
> > stephan@blue-yonder.com>
> > > wrote:
> > >
> > > > From an operator and Aurora developer perspective, it would be really
> > > > great to get rid of the thermos observer quickly.
> > > >
> > > > However, from a user perspective the usability gap between observer
> and
> > > > plain Mesos sandbox browsing is quite large right now. I agree with
> > > > Benjamin here that it would probably work if we generate html pages
> > ready
> > > > for user consumption.
> > > >
> > > > These are the relevant tickets in our tracker:
> > > > * https://issues.apache.org/jira/browse/AURORA-725
> > > > * https://issues.apache.org/jira/browse/AURORA-777
> > > >
> > > > 
> > > > From: ben...@gmail.com 
> > > > Sent: Friday, April 1, 2016 02:35
> > > > To: dev@aurora.apache.org
> > > > Subject: Re: Are we ready to remove the observer?
> > > >
> > > > Is there any chance we can keep the per-process cpu and ram
> utilization
> > > > stats?  That's one of the coolest things about aurora, imo.  The
> > executor
> > > > is already writing those checkpoints inside the mesos sandbox (I
> > think?),
> > > > so perhaps it could also produce the html pages that the observer
> > > currently
> > > > renders?
> > > >
> > > > On Thu, Mar 31, 2016 at 4:33 PM Zhitao Li 
> > wrote:
> > > >
> > > > > +1.
> > > > >
> > > > > On Thu, Mar 31, 2016 at 4:11 PM, Bill Farner 
> > > wrote:
> > > > >
> > > > > > Assuming that the vast majority of utility provided by the
> observer
> > > is
> > > > > > sandbox/log browsing - can we remove it and link to sandbox
> > browsing
> > > > that
> > > > > > mesos provides?
> > > > > >
> > > > > > The rest of the information could be (or already is) logged in
> the
> > > > > sandbox
> > > > > > for the rare debugging scenarios that call for it.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Zhitao Li
> > > > >
> > > >
> > >
> >
>

Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner 
>
> 2) Providing an easy view of a process's command-line
> 3) Providing a holistic view of the task config


Just to check my understanding - these could be trivially handled in
text/log format, right?

On Mon, Apr 4, 2016 at 9:30 AM, Joshua Cohen  wrote:

> I'm -1 on this until we have an actual replacement for the Observer. I
> think that the observer provides significant value outside of just sandbox
> browsing:
>
> 1) Exporting task-level statistics.
> 2) Providing an easy view of a process's command-line
> 3) Providing a holistic view of the task config
> 4) Real time utilization stats
>
> As a cluster operator, I use all of these features on a daily basis
> (especially when I'm on call) in addition to sandbox browsing, so I don't
> think that these uses cases are that rare.
>
> On Fri, Apr 1, 2016 at 6:55 AM, Steve Niemitz  wrote:
>
> > The per-process stats have never been very useful to us (since they don't
> > work for docker), however, even being able to see the processes that are
> > running, how many times they've restarted, when they launched, etc is
> > invaluable.
> >
> > I think there would be big pushback from users if they were to lose the
> > functionality it provided currently (beyond log viewing).
> >
> > On Fri, Apr 1, 2016 at 6:58 AM, Erb, Stephan <
> stephan@blue-yonder.com>
> > wrote:
> >
> > > From an operator and Aurora developer perspective, it would be really
> > > great to get rid of the thermos observer quickly.
> > >
> > > However, from a user perspective the usability gap between observer and
> > > plain Mesos sandbox browsing is quite large right now. I agree with
> > > Benjamin here that it would probably work if we generate html pages
> ready
> > > for user consumption.
> > >
> > > These are the relevant tickets in our tracker:
> > > * https://issues.apache.org/jira/browse/AURORA-725
> > > * https://issues.apache.org/jira/browse/AURORA-777
> > >
> > > 
> > > From: ben...@gmail.com 
> > > Sent: Friday, April 1, 2016 02:35
> > > To: dev@aurora.apache.org
> > > Subject: Re: Are we ready to remove the observer?
> > >
> > > Is there any chance we can keep the per-process cpu and ram utilization
> > > stats?  That's one of the coolest things about aurora, imo.  The
> executor
> > > is already writing those checkpoints inside the mesos sandbox (I
> think?),
> > > so perhaps it could also produce the html pages that the observer
> > currently
> > > renders?
> > >
> > > On Thu, Mar 31, 2016 at 4:33 PM Zhitao Li 
> wrote:
> > >
> > > > +1.
> > > >
> > > > On Thu, Mar 31, 2016 at 4:11 PM, Bill Farner 
> > wrote:
> > > >
> > > > > Assuming that the vast majority of utility provided by the observer
> > is
> > > > > sandbox/log browsing - can we remove it and link to sandbox
> browsing
> > > that
> > > > > mesos provides?
> > > > >
> > > > > The rest of the information could be (or already is) logged in the
> > > > sandbox
> > > > > for the rare debugging scenarios that call for it.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Zhitao Li
> > > >
> > >
> >
>