Re: Review Request 56062: Fix flapping TestRunnerKillProcessGroup test

2017-01-30 Thread Zameer Manji 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56062/#review163564
---


Ship it!




Ship It!

- Zameer Manji


On Jan. 29, 2017, 9:53 a.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56062/
> ---
> 
> (Updated Jan. 29, 2017, 9:53 a.m.)
> 
> 
> Review request for Aurora and Zameer Manji.
> 
> 
> Bugs: AURORA-1809
> https://issues.apache.org/jira/browse/AURORA-1809
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> The test was working when run in isolation, but failed when executing the 
> entire Thermos test suite.
> 
> 
> Diffs
> -
> 
>   src/test/python/apache/thermos/core/test_staged_kill.py 
> 4de735f94d9faa9772f9d336186ddd13ea78988d 
> 
> Diff: https://reviews.apache.org/r/56062/diff/
> 
> 
> Testing
> ---
> 
> ./pants test.pytest src/test/python/apache/thermos:: -- -v
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread David McLaughlin 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163562
---


Ship it!




Ship It!

- David McLaughlin


On Jan. 30, 2017, 12:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
> ---
> 
> (Updated Jan. 30, 2017, 12:55 p.m.)
> 
> 
> Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1879
> https://issues.apache.org/jira/browse/AURORA-1879
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Central idea of this patch is to change the return value of 
> `getPendingReasons` from a map keyed by JobKey to a map keyed by 
> `TaskGroupKey`. This prevents the `IllegalArgumentException` during the map 
> construction.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
> 457107090351330e68941b039ce87b9a3a124971 
>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
> 1c015a20853b1bc02033bdc925d3d8fc55896de1 
>   src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
> b71669f7aed58ea87bd3a23e45ff74efa1420aec 
>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
> 195d083166edcb0531b221dc5088216bd6a387f3 
> 
> Diff: https://reviews.apache.org/r/56058/diff/
> 
> 
> Testing
> ---
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 55982: Move deprecated resource validations so they happen after the thrift backfill

2017-01-30 Thread Zameer Manji 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55982/#review163551
---



This is on master now.

- Zameer Manji


On Jan. 30, 2017, 10:23 a.m., Nicolás Donatucci wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55982/
> ---
> 
> (Updated Jan. 30, 2017, 10:23 a.m.)
> 
> 
> Review request for Aurora, Stephan Erb and Zameer Manji.
> 
> 
> Bugs: AURORA-1707
> https://issues.apache.org/jira/browse/AURORA-1707
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> As the validations for NumCpus, RamMb and DiskMb happened before the thrift 
> backfill, those values needed to be set, even though they are deprecated. In 
> the thrift backfill, if the Resources field is set, then NumCpus, RamMb and 
> DiskMb are set accordingly. 
> 
> So by moving those validations, it is now possible to only set the Resources 
> field instead of having to set the deprecated fields. As the validations are 
> moved and not removed, the ckeck for the resource values being greater than 0 
> still happens. Furthermore, if the Resources field is set but there is no 
> Resource for Ram in the set, the thrift backfill will throw an 
> IllegalArgumentException.
> 
> Some tests were slightly modified because of this, mostly by adding an 
> unsetResources() operation. This is because as the validations now happen 
> after the thrift backfill, during the thrift backfill the values in the 
> deprecated fields are replaced by those in the Resources field (if it is 
> set). There are also some new tests.
> 
> Related Issue: AURORA-1707
> 
> 
> Diffs
> -
> 
>   
> src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
>  f96cd7a8eba12c286ac4e104a22ae74d8d4108d7 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImplTest.java
>  6d0e9bc6a8040393875d4f0a88e8db9d6926a88b 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
>  b28cd2489a52041a8e7e53f298fad8d8cd29406f 
> 
> Diff: https://reviews.apache.org/r/55982/diff/
> 
> 
> Testing
> ---
> 
> src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> 
> Thanks,
> 
> Nicolás Donatucci
> 
>

Re: Review Request 55982: Move deprecated resource validations so they happen after the thrift backfill

2017-01-30 Thread Zameer Manji 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55982/#review163550
---


Ship it!




Ship It!

- Zameer Manji


On Jan. 30, 2017, 10:23 a.m., Nicolás Donatucci wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55982/
> ---
> 
> (Updated Jan. 30, 2017, 10:23 a.m.)
> 
> 
> Review request for Aurora, Stephan Erb and Zameer Manji.
> 
> 
> Bugs: AURORA-1707
> https://issues.apache.org/jira/browse/AURORA-1707
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> As the validations for NumCpus, RamMb and DiskMb happened before the thrift 
> backfill, those values needed to be set, even though they are deprecated. In 
> the thrift backfill, if the Resources field is set, then NumCpus, RamMb and 
> DiskMb are set accordingly. 
> 
> So by moving those validations, it is now possible to only set the Resources 
> field instead of having to set the deprecated fields. As the validations are 
> moved and not removed, the ckeck for the resource values being greater than 0 
> still happens. Furthermore, if the Resources field is set but there is no 
> Resource for Ram in the set, the thrift backfill will throw an 
> IllegalArgumentException.
> 
> Some tests were slightly modified because of this, mostly by adding an 
> unsetResources() operation. This is because as the validations now happen 
> after the thrift backfill, during the thrift backfill the values in the 
> deprecated fields are replaced by those in the Resources field (if it is 
> set). There are also some new tests.
> 
> Related Issue: AURORA-1707
> 
> 
> Diffs
> -
> 
>   
> src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
>  f96cd7a8eba12c286ac4e104a22ae74d8d4108d7 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImplTest.java
>  6d0e9bc6a8040393875d4f0a88e8db9d6926a88b 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
>  b28cd2489a52041a8e7e53f298fad8d8cd29406f 
> 
> Diff: https://reviews.apache.org/r/55982/diff/
> 
> 
> Testing
> ---
> 
> src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> 
> Thanks,
> 
> Nicolás Donatucci
> 
>

Re: Review Request 55982: Move deprecated resource validations so they happen after the thrift backfill

2017-01-30 Thread Aurora ReviewBot 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55982/#review163541
---


Ship it!




Master (7be7ad6) is green with this patch.
  ./build-support/jenkins/build.sh

I will refresh this build result if you post a review containing "@ReviewBot 
retry"

- Aurora ReviewBot


On Jan. 30, 2017, 6:23 p.m., Nicolás Donatucci wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55982/
> ---
> 
> (Updated Jan. 30, 2017, 6:23 p.m.)
> 
> 
> Review request for Aurora, Stephan Erb and Zameer Manji.
> 
> 
> Bugs: AURORA-1707
> https://issues.apache.org/jira/browse/AURORA-1707
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> As the validations for NumCpus, RamMb and DiskMb happened before the thrift 
> backfill, those values needed to be set, even though they are deprecated. In 
> the thrift backfill, if the Resources field is set, then NumCpus, RamMb and 
> DiskMb are set accordingly. 
> 
> So by moving those validations, it is now possible to only set the Resources 
> field instead of having to set the deprecated fields. As the validations are 
> moved and not removed, the ckeck for the resource values being greater than 0 
> still happens. Furthermore, if the Resources field is set but there is no 
> Resource for Ram in the set, the thrift backfill will throw an 
> IllegalArgumentException.
> 
> Some tests were slightly modified because of this, mostly by adding an 
> unsetResources() operation. This is because as the validations now happen 
> after the thrift backfill, during the thrift backfill the values in the 
> deprecated fields are replaced by those in the Resources field (if it is 
> set). There are also some new tests.
> 
> Related Issue: AURORA-1707
> 
> 
> Diffs
> -
> 
>   
> src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
>  f96cd7a8eba12c286ac4e104a22ae74d8d4108d7 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImplTest.java
>  6d0e9bc6a8040393875d4f0a88e8db9d6926a88b 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
>  b28cd2489a52041a8e7e53f298fad8d8cd29406f 
> 
> Diff: https://reviews.apache.org/r/55982/diff/
> 
> 
> Testing
> ---
> 
> src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> 
> Thanks,
> 
> Nicolás Donatucci
> 
>

Re: Review Request 55982: Move deprecated resource validations so they happen after the thrift backfill

2017-01-30 Thread Nicolás Donatucci 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55982/
---

(Updated Jan. 30, 2017, 6:23 p.m.)


Review request for Aurora, Stephan Erb and Zameer Manji.


Changes
---

Deleted the outdated comment.


Bugs: AURORA-1707
https://issues.apache.org/jira/browse/AURORA-1707


Repository: aurora


Description
---

As the validations for NumCpus, RamMb and DiskMb happened before the thrift 
backfill, those values needed to be set, even though they are deprecated. In 
the thrift backfill, if the Resources field is set, then NumCpus, RamMb and 
DiskMb are set accordingly. 

So by moving those validations, it is now possible to only set the Resources 
field instead of having to set the deprecated fields. As the validations are 
moved and not removed, the ckeck for the resource values being greater than 0 
still happens. Furthermore, if the Resources field is set but there is no 
Resource for Ram in the set, the thrift backfill will throw an 
IllegalArgumentException.

Some tests were slightly modified because of this, mostly by adding an 
unsetResources() operation. This is because as the validations now happen after 
the thrift backfill, during the thrift backfill the values in the deprecated 
fields are replaced by those in the Resources field (if it is set). There are 
also some new tests.

Related Issue: AURORA-1707


Diffs (updated)
-

  
src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
 f96cd7a8eba12c286ac4e104a22ae74d8d4108d7 
  
src/test/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImplTest.java 
6d0e9bc6a8040393875d4f0a88e8db9d6926a88b 
  
src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
 b28cd2489a52041a8e7e53f298fad8d8cd29406f 

Diff: https://reviews.apache.org/r/55982/diff/


Testing
---

src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh


Thanks,

Nicolás Donatucci

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Pradyumna Kaushik 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163518
---


Ship it!




- Pradyumna Kaushik


On Jan. 30, 2017, 12:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
> ---
> 
> (Updated Jan. 30, 2017, 12:55 p.m.)
> 
> 
> Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1879
> https://issues.apache.org/jira/browse/AURORA-1879
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Central idea of this patch is to change the return value of 
> `getPendingReasons` from a map keyed by JobKey to a map keyed by 
> `TaskGroupKey`. This prevents the `IllegalArgumentException` during the map 
> construction.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
> 457107090351330e68941b039ce87b9a3a124971 
>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
> 1c015a20853b1bc02033bdc925d3d8fc55896de1 
>   src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
> b71669f7aed58ea87bd3a23e45ff74efa1420aec 
>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
> 195d083166edcb0531b221dc5088216bd6a387f3 
> 
> Diff: https://reviews.apache.org/r/56058/diff/
> 
> 
> Testing
> ---
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Pradyumna Kaushik 


> On Jan. 30, 2017, 2:32 p.m., Pradyumna Kaushik wrote:
> >

Ship it!


- Pradyumna


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163518
---


On Jan. 30, 2017, 12:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
> ---
> 
> (Updated Jan. 30, 2017, 12:55 p.m.)
> 
> 
> Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1879
> https://issues.apache.org/jira/browse/AURORA-1879
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Central idea of this patch is to change the return value of 
> `getPendingReasons` from a map keyed by JobKey to a map keyed by 
> `TaskGroupKey`. This prevents the `IllegalArgumentException` during the map 
> construction.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
> 457107090351330e68941b039ce87b9a3a124971 
>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
> 1c015a20853b1bc02033bdc925d3d8fc55896de1 
>   src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
> b71669f7aed58ea87bd3a23e45ff74efa1420aec 
>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
> 195d083166edcb0531b221dc5088216bd6a387f3 
> 
> Diff: https://reviews.apache.org/r/56058/diff/
> 
> 
> Testing
> ---
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Aurora ReviewBot 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163509
---


Ship it!




Master (7be7ad6) is green with this patch.
  ./build-support/jenkins/build.sh

I will refresh this build result if you post a review containing "@ReviewBot 
retry"

- Aurora ReviewBot


On Jan. 30, 2017, 12:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
> ---
> 
> (Updated Jan. 30, 2017, 12:55 p.m.)
> 
> 
> Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1879
> https://issues.apache.org/jira/browse/AURORA-1879
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Central idea of this patch is to change the return value of 
> `getPendingReasons` from a map keyed by JobKey to a map keyed by 
> `TaskGroupKey`. This prevents the `IllegalArgumentException` during the map 
> construction.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
> 457107090351330e68941b039ce87b9a3a124971 
>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
> 1c015a20853b1bc02033bdc925d3d8fc55896de1 
>   src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
> b71669f7aed58ea87bd3a23e45ff74efa1420aec 
>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
> 195d083166edcb0531b221dc5088216bd6a387f3 
> 
> Diff: https://reviews.apache.org/r/56058/diff/
> 
> 
> Testing
> ---
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Stephan Erb 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163504
---



@ReviewBot retry

- Stephan Erb


On Jan. 30, 2017, 1:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
> ---
> 
> (Updated Jan. 30, 2017, 1:55 p.m.)
> 
> 
> Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1879
> https://issues.apache.org/jira/browse/AURORA-1879
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Central idea of this patch is to change the return value of 
> `getPendingReasons` from a map keyed by JobKey to a map keyed by 
> `TaskGroupKey`. This prevents the `IllegalArgumentException` during the map 
> construction.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
> 457107090351330e68941b039ce87b9a3a124971 
>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
> 1c015a20853b1bc02033bdc925d3d8fc55896de1 
>   src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
> b71669f7aed58ea87bd3a23e45ff74efa1420aec 
>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
> 195d083166edcb0531b221dc5088216bd6a387f3 
> 
> Diff: https://reviews.apache.org/r/56058/diff/
> 
> 
> Testing
> ---
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Aurora ReviewBot 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/#review163502
---



Master (7be7ad6) is red with this patch.
  ./build-support/jenkins/build.sh

  Running setup.py clean for pycparser
  Running setup.py bdist_wheel for twitter.common.options: started
  Running setup.py bdist_wheel for twitter.common.options: finished with status 
'error'
  Complete output from command 
/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/pants.YHI7Pi/install/bin/python
 -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-cvQGx6/twitter.common.options/setup.py';exec(compile(getattr(tokenize,
 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
bdist_wheel -d /tmp/tmpJOTTxEpip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/twitter
  copying src/twitter/__init__.py -> build/lib.linux-x86_64-2.7/twitter
  creating build/lib.linux-x86_64-2.7/twitter/common
  copying src/twitter/common/__init__.py -> 
build/lib.linux-x86_64-2.7/twitter/common
  error: package directory 'src/twitter/common/options' does not exist
  
  
  Failed building wheel for twitter.common.options
  Running setup.py clean for twitter.common.options
Successfully built pantsbuild.pants twitter.common.collections setproctitle 
ansicolors pathspec scandir twitter.common.dirutil psutil pystache docutils 
Markdown Pygments twitter.common.confluence coverage
Failed to build lmdb pywatchman twitter.common.lang twitter.common.log 
pycparser twitter.common.options
Installing collected packages: twitter.common.lang, twitter.common.collections, 
setproctitle, setuptools, six, ansicolors, pyparsing, packaging, pathspec, 
scandir, twitter.common.dirutil, psutil, requests, pystache, pex, docutils, 
Markdown, Pygments, twitter.common.options, twitter.common.log, 
twitter.common.confluence, monotonic, fasteners, coverage, pycparser, cffi, 
lmdb, pywatchman, futures, pantsbuild.pants
  Running setup.py install for twitter.common.lang: started
Running setup.py install for twitter.common.lang: finished with status 
'error'
Complete output from command 
/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/pants.YHI7Pi/install/bin/python
 -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-cvQGx6/twitter.common.lang/setup.py';exec(compile(getattr(tokenize,
 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
install --record /tmp/pip-9VrWjU-record/install-record.txt 
--single-version-externally-managed --compile --install-headers 
/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/pants.YHI7Pi/install/include/site/python2.7/twitter.common.lang:
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/twitter
copying src/twitter/__init__.py -> build/lib.linux-x86_64-2.7/twitter
creating build/lib.linux-x86_64-2.7/twitter/common
copying src/twitter/common/__init__.py -> 
build/lib.linux-x86_64-2.7/twitter/common
error: package directory 'src/twitter/common/lang' does not exist


Command 
"/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/pants.YHI7Pi/install/bin/python
 -u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-cvQGx6/twitter.common.lang/setup.py';exec(compile(getattr(tokenize,
 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
install --record /tmp/pip-9VrWjU-record/install-record.txt 
--single-version-externally-managed --compile --install-headers 
/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/pants.YHI7Pi/install/include/site/python2.7/twitter.common.lang"
 failed with error code 1 in /tmp/pip-build-cvQGx6/twitter.common.lang/
You are using pip version 8.1.2, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
/home/jenkins/jenkins-slave/workspace/AuroraBot/build-support/python/../../pants:
 line 99: 
/home/jenkins/jenkins-slave/workspace/AuroraBot/.home/.cache/pants/setup/bootstrap-Linux-x86_64/1.3.0.dev3/bin/python:
 No such file or directory


I will refresh this build result if you post a review containing "@ReviewBot 
retry"

- Aurora ReviewBot


On Jan. 30, 2017, 12:55 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56058/
>

Re: Review Request 55089: AURORA-1826 Expose Thrift server request workload stats

2017-01-30 Thread Stephan Erb 


> On Jan. 28, 2017, 12:37 a.m., Stephan Erb wrote:
> > src/main/java/org/apache/aurora/scheduler/thrift/aop/ThriftStatsExporterInterceptor.java,
> >  lines 65-72
> > 
> >
> > Can `invocation.proceed();` ever return `null`?
> > 
> > If not, then we could move the new counter code from the `finally` to 
> > the `try` block and eliminate the `response != null` guard.
> 
> Mehrdad Nurolahzade wrote:
> `response != null` guard is a necessary protection from the corner case 
> when `invocation.proceed()` throws an exception.

If we move the whole code block into the try block, shortly behind 
`invocation.proceed()` then we don't need the `response != null` guard any 
longer. 

But this is only a minor thing. I will apply the patch now without the change.


- Stephan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/55089/#review163351
---


On Jan. 28, 2017, 10:11 p.m., Mehrdad Nurolahzade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55089/
> ---
> 
> (Updated Jan. 28, 2017, 10:11 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Stephan Erb.
> 
> 
> Bugs: AURORA-1826
> https://issues.apache.org/jira/browse/AURORA-1826
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> This patch introduces a number of stats that measure the workload generated 
> by Thrift server requests.
> 
> Current Thrift server stats expose the number and timing of requests received 
> by the server. However, they fail to reflect the size of the requests. This 
> is limiting us in having an accurate view of the workload handled by the 
> scheduler. For example, every call to `restartShards()` is recorded as one 
> event despite the fact that a request might only restart one shard while 
> another request might seek to restart 1K shards.
> 
> 
> Diffs
> -
> 
>   
> src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
>  16b1b52f8691d978a9ec1bf7aa0c9716b3484cf0 
>   
> src/main/java/org/apache/aurora/scheduler/thrift/aop/ThriftStatsExporterInterceptor.java
>  d57f910d8f9bbe5c24aec960e88d03702bc353da 
>   src/main/java/org/apache/aurora/scheduler/thrift/aop/ThriftWorkload.java 
> PRE-CREATION 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
>  b28cd2489a52041a8e7e53f298fad8d8cd29406f 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/aop/ThriftStatsExporterInterceptorTest.java
>  9c40ec51c28c8c57365dc21c3cd7391a3894784c 
> 
> Diff: https://reviews.apache.org/r/55089/diff/
> 
> 
> Testing
> ---
> 
> ```
> curl 192.168.33.7:8081/vars | grep thrift_workload
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100 413340 413340 0  3695k  0 --:--:-- --:--:-- --:--:-- 4036k
> thrift_workload_addInstances 0
> thrift_workload_createJob 0
> thrift_workload_createOrUpdateCronTemplate 0
> thrift_workload_drainHosts 0
> thrift_workload_endMaintenance 0
> thrift_workload_getConfigSummary 0
> thrift_workload_getJobSummary 0
> thrift_workload_getJobUpdateDetails 0
> thrift_workload_getJobUpdateSummaries 0
> thrift_workload_getJobs 0
> thrift_workload_getPendingReason 0
> thrift_workload_getRoleSummary 0
> thrift_workload_getTaskStatus 0
> thrift_workload_getTasksWithoutConfigs 0
> thrift_workload_killTasks 0
> thrift_workload_maintenanceStatus 0
> thrift_workload_restartShards 0
> thrift_workload_rewriteConfigs 0
> thrift_workload_startJobUpdate 0
> thrift_workload_startMaintenance 0
> ```
> 
> ```
> ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> ...
> 
> *** OK (All tests passed) ***
> 
> mesos-master start/running, process 2359
> + RETCODE=0
> + restore_netrc
> + mv /home/vagrant/.netrc.bak /home/vagrant/.netrc
> + true
> Connection to 127.0.0.1 closed.
> 
> real  28m58.389s
> user  0m1.508s
> sys   0m0.820s
> ```
> 
> 
> Thanks,
> 
> Mehrdad Nurolahzade
> 
>

Re: Review Request 56058: Fix pendingTasks endpoint in case of multiple TaskGroups per job

2017-01-30 Thread Stephan Erb 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56058/
---

(Updated Jan. 30, 2017, 1:55 p.m.)


Review request for Aurora, Pradyumna Kaushik and Santhosh Kumar Shanmugham.


Changes
---

Fix code comments.


Bugs: AURORA-1879
https://issues.apache.org/jira/browse/AURORA-1879


Repository: aurora


Description
---

Central idea of this patch is to change the return value of `getPendingReasons` 
from a map keyed by JobKey to a map keyed by `TaskGroupKey`. This prevents the 
`IllegalArgumentException` during the map construction.


Diffs (updated)
-

  src/main/java/org/apache/aurora/scheduler/http/PendingTasks.java 
457107090351330e68941b039ce87b9a3a124971 
  src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
1c015a20853b1bc02033bdc925d3d8fc55896de1 
  src/test/java/org/apache/aurora/scheduler/http/PendingTasksTest.java 
b71669f7aed58ea87bd3a23e45ff74efa1420aec 
  src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
195d083166edcb0531b221dc5088216bd6a387f3 

Diff: https://reviews.apache.org/r/56058/diff/


Testing
---

./gradlew -Pq build


Thanks,

Stephan Erb