Re: Review Request 28879: Make abstract decorators effective in CommandHook class

2014-12-11 Thread Maxim Khutornenko

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


On master now.

- Maxim Khutornenko


On Dec. 9, 2014, 11:36 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28879/
 ---
 
 (Updated Dec. 9, 2014, 11:36 p.m.)
 
 
 Review request for Aurora and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This makes the CommandHook class inherit from AbstractClass.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/command_hooks.py 
 aa850bf941bede1d3bd8aae4811cb094ba77965f 
   src/test/python/apache/aurora/client/cli/AuroraHooks 
 e27fcc81d6092b3b42f9a2948e3955d8f6963a14 
   
 src/test/python/apache/aurora/client/cli/hook_test_data/exec_error/AuroraHooks
  5dc5907b9ae87632f91084e43be319c6f1b4f437 
 
 Diff: https://reviews.apache.org/r/28879/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli::
 
 
 Thanks,
 
 Zameer Manji
 




Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko

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

Review request for Aurora, Kevin Sweeney and Bill Farner.


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


Repository: aurora


Description
---

Adding PMD rule to check @Timed annotation placement.


Diffs
-

  config/pmd/design.xml 2741e407e35826e73bd4dc8335c0ef6294086398 

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


Testing
---

```
$ ./gradlew -Pq --rerun-tasks pmdMain
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
:pmdMain
/Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
   A method must be overridable to have a @Timed annotation.
:pmdMain FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':pmdMain'.
 1 PMD rule violations were found. See the report at: 
 file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 12.981 secs
```


Thanks,

Maxim Khutornenko



Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko

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

(Updated Dec. 10, 2014, 8:02 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

Fixed description.


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


Repository: aurora


Description
---

Adding PMD rule to check @Timed annotation placement.


Diffs (updated)
-

  config/pmd/design.xml 2741e407e35826e73bd4dc8335c0ef6294086398 

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


Testing
---

```
$ ./gradlew -Pq --rerun-tasks pmdMain
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
:pmdMain
/Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
   A method must be overridable to have a @Timed annotation.
:pmdMain FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':pmdMain'.
 1 PMD rule violations were found. See the report at: 
 file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 12.981 secs
```


Thanks,

Maxim Khutornenko



Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 10, 2014, 8 p.m., Kevin Sweeney wrote:
  config/pmd/design.xml, lines 1914-1915
  https://reviews.apache.org/r/28914/diff/1/?file=788485#file788485line1914
 
  Fix description?

Yup, just noticed and updated.


- Maxim


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


On Dec. 10, 2014, 8:02 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28914/
 ---
 
 (Updated Dec. 10, 2014, 8:02 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Bugs: AURORA-967
 https://issues.apache.org/jira/browse/AURORA-967
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding PMD rule to check @Timed annotation placement.
 
 
 Diffs
 -
 
   config/pmd/design.xml 2741e407e35826e73bd4dc8335c0ef6294086398 
 
 Diff: https://reviews.apache.org/r/28914/diff/
 
 
 Testing
 ---
 
 ```
 $ ./gradlew -Pq --rerun-tasks pmdMain
 :buildSrc:compileJava UP-TO-DATE
 :buildSrc:compileGroovy
 :buildSrc:processResources UP-TO-DATE
 :buildSrc:classes
 :buildSrc:jar
 :buildSrc:assemble
 :buildSrc:compileTestJava UP-TO-DATE
 :buildSrc:compileTestGroovy UP-TO-DATE
 :buildSrc:processTestResources UP-TO-DATE
 :buildSrc:testClasses UP-TO-DATE
 :buildSrc:test UP-TO-DATE
 :buildSrc:check UP-TO-DATE
 :buildSrc:build
 :pmdMain
 /Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
  A method must be overridable to have a @Timed annotation.
 :pmdMain FAILED
 
 FAILURE: Build failed with an exception.
 
 * What went wrong:
 Execution failed for task ':pmdMain'.
  1 PMD rule violations were found. See the report at: 
  file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html
 
 * Try:
 Run with --stacktrace option to get the stack trace. Run with --info or 
 --debug option to get more log output.
 
 BUILD FAILED
 
 Total time: 12.981 secs
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 10, 2014, 8:01 p.m., Kevin Sweeney wrote:
  config/pmd/design.xml, line 1909
  https://reviews.apache.org/r/28914/diff/1/?file=788485#file788485line1909
 
  Also, consider adding this to a custom.xml file.

Good idea. Done.


- Maxim


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


On Dec. 10, 2014, 8:02 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28914/
 ---
 
 (Updated Dec. 10, 2014, 8:02 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Bugs: AURORA-967
 https://issues.apache.org/jira/browse/AURORA-967
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding PMD rule to check @Timed annotation placement.
 
 
 Diffs
 -
 
   config/pmd/design.xml 2741e407e35826e73bd4dc8335c0ef6294086398 
 
 Diff: https://reviews.apache.org/r/28914/diff/
 
 
 Testing
 ---
 
 ```
 $ ./gradlew -Pq --rerun-tasks pmdMain
 :buildSrc:compileJava UP-TO-DATE
 :buildSrc:compileGroovy
 :buildSrc:processResources UP-TO-DATE
 :buildSrc:classes
 :buildSrc:jar
 :buildSrc:assemble
 :buildSrc:compileTestJava UP-TO-DATE
 :buildSrc:compileTestGroovy UP-TO-DATE
 :buildSrc:processTestResources UP-TO-DATE
 :buildSrc:testClasses UP-TO-DATE
 :buildSrc:test UP-TO-DATE
 :buildSrc:check UP-TO-DATE
 :buildSrc:build
 :pmdMain
 /Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
  A method must be overridable to have a @Timed annotation.
 :pmdMain FAILED
 
 FAILURE: Build failed with an exception.
 
 * What went wrong:
 Execution failed for task ':pmdMain'.
  1 PMD rule violations were found. See the report at: 
  file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html
 
 * Try:
 Run with --stacktrace option to get the stack trace. Run with --info or 
 --debug option to get more log output.
 
 BUILD FAILED
 
 Total time: 12.981 secs
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko

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

(Updated Dec. 10, 2014, 8:06 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

Kevin's comments.


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


Repository: aurora


Description
---

Adding PMD rule to check @Timed annotation placement.


Diffs (updated)
-

  config/pmd/custom.xml PRE-CREATION 

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


Testing
---

```
$ ./gradlew -Pq --rerun-tasks pmdMain
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
:pmdMain
/Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
   A method must be overridable to have a @Timed annotation.
:pmdMain FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':pmdMain'.
 1 PMD rule violations were found. See the report at: 
 file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 12.981 secs
```


Thanks,

Maxim Khutornenko



Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 10, 2014, 9:07 p.m., Bill Farner wrote:
  config/pmd/design.xml, line 1923
  https://reviews.apache.org/r/28914/diff/2/?file=788486#file788486line1923
 
  Should this be =1?  JDK8 supports multiple annotations of the same 
  type, so while silly it might be good to keep in mind.

Sure, 0 does the trick.


- Maxim


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


On Dec. 10, 2014, 8:06 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28914/
 ---
 
 (Updated Dec. 10, 2014, 8:06 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Bugs: AURORA-967
 https://issues.apache.org/jira/browse/AURORA-967
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding PMD rule to check @Timed annotation placement.
 
 
 Diffs
 -
 
   config/pmd/custom.xml PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28914/diff/
 
 
 Testing
 ---
 
 ```
 $ ./gradlew -Pq --rerun-tasks pmdMain
 :buildSrc:compileJava UP-TO-DATE
 :buildSrc:compileGroovy
 :buildSrc:processResources UP-TO-DATE
 :buildSrc:classes
 :buildSrc:jar
 :buildSrc:assemble
 :buildSrc:compileTestJava UP-TO-DATE
 :buildSrc:compileTestGroovy UP-TO-DATE
 :buildSrc:processTestResources UP-TO-DATE
 :buildSrc:testClasses UP-TO-DATE
 :buildSrc:test UP-TO-DATE
 :buildSrc:check UP-TO-DATE
 :buildSrc:build
 :pmdMain
 /Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
  A method must be overridable to have a @Timed annotation.
 :pmdMain FAILED
 
 FAILURE: Build failed with an exception.
 
 * What went wrong:
 Execution failed for task ':pmdMain'.
  1 PMD rule violations were found. See the report at: 
  file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html
 
 * Try:
 Run with --stacktrace option to get the stack trace. Run with --info or 
 --debug option to get more log output.
 
 BUILD FAILED
 
 Total time: 12.981 secs
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 10, 2014, 8:31 p.m., Kevin Sweeney wrote:
  config/pmd/custom.xml, line 21
  https://reviews.apache.org/r/28914/diff/3/?file=788487#file788487line21
 
  Name = Aurora?

Sure.


 On Dec. 10, 2014, 8:31 p.m., Kevin Sweeney wrote:
  config/pmd/custom.xml, line 15
  https://reviews.apache.org/r/28914/diff/3/?file=788487#file788487line15
 
  Remove this comment.

Removed.


 On Dec. 10, 2014, 8:31 p.m., Kevin Sweeney wrote:
  config/pmd/custom.xml, line 36
  https://reviews.apache.org/r/28914/diff/3/?file=788487#file788487line36
 
  Used with the @Timed annotation. Also consider adding a link to the 
  guice docs on method interceptor limitations for those unfamiliar.

Added.


 On Dec. 10, 2014, 8:31 p.m., Kevin Sweeney wrote:
  config/pmd/custom.xml, line 43
  https://reviews.apache.org/r/28914/diff/3/?file=788487#file788487line43
 
  My XPath-foo is lacking - will this catch all of the following forms:
  
  ```java
  @Timed(test_var)
  private void myMethod() {}
  
  @Timed
  void myMethod2() {}
  
  @Timed(value = time_var)
  static void myMethod3() {}
  ```
  
  Also is there a way to limit this match to the Timed annotation from 
  com.twitter.common.inject.TimedInterceptor.Timed?

Modifed to support all use cases.

As for the type resolution, this would be much more involved and would require 
implementing part of the rule in java to use ClassLoader. I am punting on this.


- Maxim


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


On Dec. 10, 2014, 8:06 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28914/
 ---
 
 (Updated Dec. 10, 2014, 8:06 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Bugs: AURORA-967
 https://issues.apache.org/jira/browse/AURORA-967
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding PMD rule to check @Timed annotation placement.
 
 
 Diffs
 -
 
   config/pmd/custom.xml PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28914/diff/
 
 
 Testing
 ---
 
 ```
 $ ./gradlew -Pq --rerun-tasks pmdMain
 :buildSrc:compileJava UP-TO-DATE
 :buildSrc:compileGroovy
 :buildSrc:processResources UP-TO-DATE
 :buildSrc:classes
 :buildSrc:jar
 :buildSrc:assemble
 :buildSrc:compileTestJava UP-TO-DATE
 :buildSrc:compileTestGroovy UP-TO-DATE
 :buildSrc:processTestResources UP-TO-DATE
 :buildSrc:testClasses UP-TO-DATE
 :buildSrc:test UP-TO-DATE
 :buildSrc:check UP-TO-DATE
 :buildSrc:build
 :pmdMain
 /Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
  A method must be overridable to have a @Timed annotation.
 :pmdMain FAILED
 
 FAILURE: Build failed with an exception.
 
 * What went wrong:
 Execution failed for task ':pmdMain'.
  1 PMD rule violations were found. See the report at: 
  file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html
 
 * Try:
 Run with --stacktrace option to get the stack trace. Run with --info or 
 --debug option to get more log output.
 
 BUILD FAILED
 
 Total time: 12.981 secs
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28914: Adding PMD rule to check @Timed annotation placement.

2014-12-10 Thread Maxim Khutornenko

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

(Updated Dec. 10, 2014, 10:37 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Adding PMD rule to check @Timed annotation placement.


Diffs (updated)
-

  config/pmd/custom.xml PRE-CREATION 

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


Testing
---

```
$ ./gradlew -Pq --rerun-tasks pmdMain
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
:pmdMain
/Users/mkhutornenko/workspace3/aurora/src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java:204:
   A method must be overridable to have a @Timed annotation.
:pmdMain FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':pmdMain'.
 1 PMD rule violations were found. See the report at: 
 file:///Users/mkhutornenko/workspace3/aurora/dist/reports/pmd/main.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

BUILD FAILED

Total time: 12.981 secs
```


Thanks,

Maxim Khutornenko



Re: Review Request 28915: Use pip to pre-fetch python dependencies.

2014-12-10 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 10, 2014, 9:39 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28915/
 ---
 
 (Updated Dec. 10, 2014, 9:39 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This is to hopefully eradicate flaked builds like the following:
 ```
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/commands/build.py,
  line 130, in _python_build
 debug=self._verbose)
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/python_builder.py,
  line 43, in build
 debug=debug).run()
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/test_builder.py,
  line 88, in run
 rv = self._run_tests([target], stdout, stderr)
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/test_builder.py,
  line 316, in _run_tests
 with self._test_runner(targets, stdout, stderr) as (pex, test_args):
   File /usr/lib/python2.7/contextlib.py, line 17, in __enter__
 return self.gen.next()
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/test_builder.py,
  line 295, in _test_runner
 builder = chroot.dump()
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/python_chroot.py,
  line 191, in dump
 conn_timeout=self._conn_timeout)
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pants/backend/python/resolver.py,
  line 100, in resolve_multi
 platform=platform)
   File 
 /home/jenkins/jenkins-slave/workspace/Aurora/build-support/pants.venv/lib/python2.7/site-packages/pex/resolver.py,
  line 101, in resolve
 raise Unsatisfiable('Cannot satisfy requirements: %s' % 
 requirement_set[requirement.key])
 Unsatisfiable: Cannot satisfy requirements: 
 [PythonRequirement(pystachio==0.7.2)]
 ```
 
 Thanks to Kevin for providing the pointers here.
 
 
 Diffs
 -
 
   build-support/jenkins/build.sh 40ef938929af3729d105dcd624f1b919b1868afa 
 
 Diff: https://reviews.apache.org/r/28915/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28876: Suppressing redundant client command error messaging.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 9, 2014, 11:29 p.m., Zameer Manji wrote:
  src/main/python/apache/aurora/client/cli/__init__.py, line 384
  https://reviews.apache.org/r/28876/diff/1/?file=787343#file787343line384
 
  This solution seems to be papering over the problem we have with output 
  in the client.
  
  Instead of creating a new type of exception can we just prevent the 
  double printing in general?
 
 Maxim Khutornenko wrote:
 Not sure I buy it. This `print_err()` is needed when a CommandError is 
 raised to bail out due to some internal problem (i.e. not related to 
 scheduler call and not routed through context.check_and_log_response). The 
 fact that the same error type is used for both is exactly the reason we have 
 these redundant messages. There are plenty of legitimate cases where the 
 error needs to be logged. Consider this example:
 ```
 $ aurora2 job kill devcluster/www-data/prod/hello
 Error executing command: The instances list cannot be omitted in a kill 
 command!; use killall to kill all instances
 ```
 
 Bill Farner wrote:
 Part of the problem here is that logging to stdout/stderr happens 
 throughout the stack.  This seems to inevitably lead towards redundant 
 output.  Perhaps we should take the approach of limiting use of stdout/stderr 
 to the top of the stack whenever possible?  The only use case that seems to 
 not fit that today seems to be client-side job updates, which we could ignore 
 since it's scheduled for removal.
 
 Maxim Khutornenko wrote:
 | Perhaps we should take the approach of limiting use of stdout/stderr to 
 the top of the stack whenever possible?
 
 Agree, that would make sense. There are plenty of examples where that 
 happens. E.g. compare [1] and [2]. The first one has redundant print_err() 
 and will result in duplicate messages. The second one (used as example above) 
 only loggged by the CommineLine handler. This diff addresses a problem where 
 a redundant incomplete message is logged after unsuccessful scheduler call. I 
 suggest we tackle the [1] separately.
 
 [1] - 
 https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L342-L344
 [2] - 
 https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L368-L370
 
 Bill Farner wrote:
 Going back to Zameer's comment, though, maybe `check_and_log_response` 
 should refrain from calling `print_err`?  Seems like the receiving end of 
 `CommandError` should be responsible for presenting the error.
 
 Maxim Khutornenko wrote:
 I am not sure what it really buys us. Right now, the scheduler response 
 is entirely handled within the check_and_log_response that does centralized 
 logging to both stdout and stderr. IMO, delegating just stderr handling 
 elsewhere creates more ambiguity and is not solving any additional problems.
 
 Zameer Manji wrote:
 Maxim, if you agree to tackle the redundant print_err()/CommandError in 
 another RB I am comfortable with this change.

These are two different issues and I was going to address the other one in a 
separate RB. Filed AURORA-968 to track it.


- Maxim


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


On Dec. 9, 2014, 10:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28876/
 ---
 
 (Updated Dec. 9, 2014, 10:32 p.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-965
 https://issues.apache.org/jira/browse/AURORA-965
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Added a new error type to raise when errors are logged explicitly.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 c2eb89cae536838ac4dd46b0125a248d84f6e54c 
   src/main/python/apache/aurora/client/cli/context.py 
 ad27eb5674fb85c5d3a26a014349abdea4fa2d64 
   src/test/python/apache/aurora/client/cli/test_update.py 
 1f061a39279bf5ef9d4e7279016bf07e164014bb 
 
 Diff: https://reviews.apache.org/r/28876/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli:all
 
 Vagrant before:
 
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 Error executing command: Job creation failed due to error:
 ```
 
 Vagrant after:
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 ```
 
 
 Thanks

Re: Review Request 28872: Improving quota check message in the client.

2014-12-10 Thread Maxim Khutornenko

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

(Updated Dec. 11, 2014, 2:54 a.m.)


Review request for Aurora, Kevin Sweeney and Zameer Manji.


Changes
---

CR comments.


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


Repository: aurora


Description
---

A minor fix improving the quota check message on the client. Minor enough to 
consider for a dying client updater.


Diffs (updated)
-

  src/main/python/apache/aurora/client/api/quota_check.py 
c994050d76a9b617f70dfcbf60cf10e02d4a4bb9 
  src/test/python/apache/aurora/client/api/test_quota_check.py 
2fc76d21ca63ae7f33b1e03ccb88f52fe82dc76c 

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


Testing
---

./pants src/test/python/apache/aurora/client/api:quota_check

Vagrant:
```
$ aurora2 job update devcluster/www-data/prod/hello 
aurora/examples/jobs/hello_world.aurora 
 INFO] 
 INFO] 
 INFO] Updating job: hello
 INFO] Not enough quota to create/update job.
 INFO] Total allocated quota for www-data:
CPU 2.0
RAM 2.00 GB
Disk2.00 GB
 INFO] Consumed quota for www-data:
CPU 1.9
RAM 1.125977 GB
Disk1.125000 GB
 INFO] Requested for hello:
CPU 9.1
RAM 0.00 GB
Disk0.00 GB
 INFO] Additional quota required for www-data:
CPU 9.0
RAM 0.00 GB
Disk0.00 GB
Update failed due to error:
Unable to start job update: Response from scheduler: INVALID_REQUEST 
(message: Failed quota check.)
Error executing command: Update failed due to error:
```


Thanks,

Maxim Khutornenko



Re: Review Request 28872: Improving quota check message in the client.

2014-12-10 Thread Maxim Khutornenko


 On Dec. 9, 2014, 11:41 p.m., Zameer Manji wrote:
  src/test/python/apache/aurora/client/api/test_quota_check.py, line 124
  https://reviews.apache.org/r/28872/diff/1/?file=787283#file787283line124
 
  Can you set all the calls to print quota?

Sure, done.


- Maxim


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


On Dec. 9, 2014, 9:30 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28872/
 ---
 
 (Updated Dec. 9, 2014, 9:30 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Zameer Manji.
 
 
 Bugs: AURORA-469
 https://issues.apache.org/jira/browse/AURORA-469
 
 
 Repository: aurora
 
 
 Description
 ---
 
 A minor fix improving the quota check message on the client. Minor enough to 
 consider for a dying client updater.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/api/quota_check.py 
 c994050d76a9b617f70dfcbf60cf10e02d4a4bb9 
   src/test/python/apache/aurora/client/api/test_quota_check.py 
 2fc76d21ca63ae7f33b1e03ccb88f52fe82dc76c 
 
 Diff: https://reviews.apache.org/r/28872/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/api:quota_check
 
 Vagrant:
 ```
 $ aurora2 job update devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] 
  INFO] 
  INFO] Updating job: hello
  INFO] Not enough quota to create/update job.
  INFO] Total allocated quota for www-data:
   CPU 2.0
   RAM 2.00 GB
   Disk2.00 GB
  INFO] Consumed quota for www-data:
   CPU 1.9
   RAM 1.125977 GB
   Disk1.125000 GB
  INFO] Requested for hello:
   CPU 9.1
   RAM 0.00 GB
   Disk0.00 GB
  INFO] Additional quota required for www-data:
   CPU 9.0
   RAM 0.00 GB
   Disk0.00 GB
 Update failed due to error:
   Unable to start job update: Response from scheduler: INVALID_REQUEST 
 (message: Failed quota check.)
 Error executing command: Update failed due to error:
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28872: Improving quota check message in the client.

2014-12-10 Thread Maxim Khutornenko

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

(Updated Dec. 11, 2014, 2:55 a.m.)


Review request for Aurora, Kevin Sweeney and Zameer Manji.


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


Repository: aurora


Description
---

A minor fix improving the quota check message on the client. Minor enough to 
consider for a dying client updater.


Diffs (updated)
-

  src/main/python/apache/aurora/client/api/quota_check.py 
c994050d76a9b617f70dfcbf60cf10e02d4a4bb9 
  src/test/python/apache/aurora/client/api/test_quota_check.py 
2fc76d21ca63ae7f33b1e03ccb88f52fe82dc76c 

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


Testing
---

./pants src/test/python/apache/aurora/client/api:quota_check

Vagrant:
```
$ aurora2 job update devcluster/www-data/prod/hello 
aurora/examples/jobs/hello_world.aurora 
 INFO] 
 INFO] 
 INFO] Updating job: hello
 INFO] Not enough quota to create/update job.
 INFO] Total allocated quota for www-data:
CPU 2.0
RAM 2.00 GB
Disk2.00 GB
 INFO] Consumed quota for www-data:
CPU 1.9
RAM 1.125977 GB
Disk1.125000 GB
 INFO] Requested for hello:
CPU 9.1
RAM 0.00 GB
Disk0.00 GB
 INFO] Additional quota required for www-data:
CPU 9.0
RAM 0.00 GB
Disk0.00 GB
Update failed due to error:
Unable to start job update: Response from scheduler: INVALID_REQUEST 
(message: Failed quota check.)
Error executing command: Update failed due to error:
```


Thanks,

Maxim Khutornenko



Re: Review Request 28831: Changing the default --batch-size to 1.

2014-12-09 Thread Maxim Khutornenko


 On Dec. 9, 2014, 2:33 a.m., Bill Farner wrote:
  src/test/python/apache/aurora/client/cli/test_kill.py, line 134
  https://reviews.apache.org/r/28831/diff/1/?file=786267#file786267line134
 
  I believe this should be of the form `assert foo.mock_calls == [x]`
  
  Ditto elsewhere.

Doh, thanks for catching. I wasn't having a good day and python made it worse 
by allowing an illegal assignment. 

Adding asserts revealed deeper problems with JobMonitor where scheduler calls 
were made in arbitrary fashion. Mocked out JobMonitor to avoid randomness. 
These tests still need more love to become truly unit rather than integration 
tests but I have to stop here to avoid a complete overhaul.


- Maxim


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


On Dec. 9, 2014, 1:25 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28831/
 ---
 
 (Updated Dec. 9, 2014, 1:25 a.m.)
 
 
 Review request for Aurora and Bill Farner.
 
 
 Bugs: AURORA-961
 https://issues.apache.org/jira/browse/AURORA-961
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Also, cleaned up kill command tests a bit.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/options.py 
 e844cf340583b631ce194352f403bbaec71655b7 
   src/test/python/apache/aurora/client/cli/test_kill.py 
 1eda72af4c19831ae27733f506858e67772b2075 
   src/test/python/apache/aurora/client/cli/util.py 
 67d7eaa6eff4e1dbaaa485166e084812a4f04074 
 
 Diff: https://reviews.apache.org/r/28831/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli:all
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28831: Changing the default --batch-size to 1.

2014-12-09 Thread Maxim Khutornenko

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

(Updated Dec. 9, 2014, 6:14 p.m.)


Review request for Aurora and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Also, cleaned up kill command tests a bit.


Diffs (updated)
-

  src/main/python/apache/aurora/client/cli/options.py 
e844cf340583b631ce194352f403bbaec71655b7 
  src/test/python/apache/aurora/client/cli/test_kill.py 
1eda72af4c19831ae27733f506858e67772b2075 
  src/test/python/apache/aurora/client/cli/util.py 
67d7eaa6eff4e1dbaaa485166e084812a4f04074 

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


Testing
---

./pants src/test/python/apache/aurora/client/cli:all


Thanks,

Maxim Khutornenko



Re: Review Request 28831: Changing the default --batch-size to 1.

2014-12-09 Thread Maxim Khutornenko

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

(Updated Dec. 9, 2014, 8:18 p.m.)


Review request for Aurora and Bill Farner.


Changes
---

Addressed Kevin's comments.


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


Repository: aurora


Description
---

Also, cleaned up kill command tests a bit.


Diffs (updated)
-

  src/main/python/apache/aurora/client/cli/options.py 
e844cf340583b631ce194352f403bbaec71655b7 
  src/test/python/apache/aurora/client/cli/test_kill.py 
1eda72af4c19831ae27733f506858e67772b2075 
  src/test/python/apache/aurora/client/cli/util.py 
67d7eaa6eff4e1dbaaa485166e084812a4f04074 

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


Testing
---

./pants src/test/python/apache/aurora/client/cli:all


Thanks,

Maxim Khutornenko



Review Request 28872: Improving quota check message in the client.

2014-12-09 Thread Maxim Khutornenko

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

Review request for Aurora, Kevin Sweeney and Zameer Manji.


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


Repository: aurora


Description
---

A minor fix improving the quota check message on the client. Minor enough to 
consider for a dying client updater.


Diffs
-

  src/main/python/apache/aurora/client/api/quota_check.py 
c994050d76a9b617f70dfcbf60cf10e02d4a4bb9 
  src/test/python/apache/aurora/client/api/test_quota_check.py 
2fc76d21ca63ae7f33b1e03ccb88f52fe82dc76c 

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


Testing
---

./pants src/test/python/apache/aurora/client/api:quota_check

Vagrant:
```
$ aurora2 job update devcluster/www-data/prod/hello 
aurora/examples/jobs/hello_world.aurora 
 INFO] 
 INFO] 
 INFO] Updating job: hello
 INFO] Not enough quota to create/update job.
 INFO] Total allocated quota for www-data:
CPU 2.0
RAM 2.00 GB
Disk2.00 GB
 INFO] Consumed quota for www-data:
CPU 1.9
RAM 1.125977 GB
Disk1.125000 GB
 INFO] Requested for hello:
CPU 9.1
RAM 0.00 GB
Disk0.00 GB
 INFO] Additional quota required for www-data:
CPU 9.0
RAM 0.00 GB
Disk0.00 GB
Update failed due to error:
Unable to start job update: Response from scheduler: INVALID_REQUEST 
(message: Failed quota check.)
Error executing command: Update failed due to error:
```


Thanks,

Maxim Khutornenko



Review Request 28876: Suppressing redundant client command error messaging.

2014-12-09 Thread Maxim Khutornenko

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

Review request for Aurora, Bill Farner and Zameer Manji.


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


Repository: aurora


Description
---

Added a new error type to raise when errors are logged explicitly.


Diffs
-

  src/main/python/apache/aurora/client/cli/__init__.py 
c2eb89cae536838ac4dd46b0125a248d84f6e54c 
  src/main/python/apache/aurora/client/cli/context.py 
ad27eb5674fb85c5d3a26a014349abdea4fa2d64 
  src/test/python/apache/aurora/client/cli/test_update.py 
1f061a39279bf5ef9d4e7279016bf07e164014bb 

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


Testing
---

./pants src/test/python/apache/aurora/client/cli:all

Vagrant before:

```
$ aurora2 job create devcluster/www-data/prod/hello 
aurora/examples/jobs/hello_world.aurora 
 INFO] Creating job hello
Job creation failed due to error:
Job already exists: www-data/prod/hello
Error executing command: Job creation failed due to error:
```

Vagrant after:
```
$ aurora2 job create devcluster/www-data/prod/hello 
aurora/examples/jobs/hello_world.aurora 
 INFO] Creating job hello
Job creation failed due to error:
Job already exists: www-data/prod/hello
```


Thanks,

Maxim Khutornenko



Re: Review Request 28876: Suppressing redundant client command error messaging.

2014-12-09 Thread Maxim Khutornenko


 On Dec. 9, 2014, 11:29 p.m., Zameer Manji wrote:
  src/main/python/apache/aurora/client/cli/__init__.py, line 384
  https://reviews.apache.org/r/28876/diff/1/?file=787343#file787343line384
 
  This solution seems to be papering over the problem we have with output 
  in the client.
  
  Instead of creating a new type of exception can we just prevent the 
  double printing in general?

Not sure I buy it. This `print_err()` is needed when a CommandError is raised 
to bail out due to some internal problem (i.e. not related to scheduler call 
and not routed through context.check_and_log_response). The fact that the same 
error type is used for both is exactly the reason we have these redundant 
messages. There are plenty of legitimate cases where the error needs to be 
logged. Consider this example:
```
$ aurora2 job kill devcluster/www-data/prod/hello
Error executing command: The instances list cannot be omitted in a kill 
command!; use killall to kill all instances
```


 On Dec. 9, 2014, 11:29 p.m., Zameer Manji wrote:
  src/test/python/apache/aurora/client/cli/test_update.py, line 69
  https://reviews.apache.org/r/28876/diff/1/?file=787345#file787345line69
 
  Is it at all possible to avoid the use of raw Mock objects?

This goes into Pystachio namespace that I am hesitant to tap into. Given the 
additional complexity I don't see much value in creating a concrete object for 
a parent-mocked container.


- Maxim


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


On Dec. 9, 2014, 10:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28876/
 ---
 
 (Updated Dec. 9, 2014, 10:32 p.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-965
 https://issues.apache.org/jira/browse/AURORA-965
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Added a new error type to raise when errors are logged explicitly.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 c2eb89cae536838ac4dd46b0125a248d84f6e54c 
   src/main/python/apache/aurora/client/cli/context.py 
 ad27eb5674fb85c5d3a26a014349abdea4fa2d64 
   src/test/python/apache/aurora/client/cli/test_update.py 
 1f061a39279bf5ef9d4e7279016bf07e164014bb 
 
 Diff: https://reviews.apache.org/r/28876/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli:all
 
 Vagrant before:
 
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 Error executing command: Job creation failed due to error:
 ```
 
 Vagrant after:
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28876: Suppressing redundant client command error messaging.

2014-12-09 Thread Maxim Khutornenko


 On Dec. 9, 2014, 11:29 p.m., Zameer Manji wrote:
  src/main/python/apache/aurora/client/cli/__init__.py, line 384
  https://reviews.apache.org/r/28876/diff/1/?file=787343#file787343line384
 
  This solution seems to be papering over the problem we have with output 
  in the client.
  
  Instead of creating a new type of exception can we just prevent the 
  double printing in general?
 
 Maxim Khutornenko wrote:
 Not sure I buy it. This `print_err()` is needed when a CommandError is 
 raised to bail out due to some internal problem (i.e. not related to 
 scheduler call and not routed through context.check_and_log_response). The 
 fact that the same error type is used for both is exactly the reason we have 
 these redundant messages. There are plenty of legitimate cases where the 
 error needs to be logged. Consider this example:
 ```
 $ aurora2 job kill devcluster/www-data/prod/hello
 Error executing command: The instances list cannot be omitted in a kill 
 command!; use killall to kill all instances
 ```
 
 Bill Farner wrote:
 Part of the problem here is that logging to stdout/stderr happens 
 throughout the stack.  This seems to inevitably lead towards redundant 
 output.  Perhaps we should take the approach of limiting use of stdout/stderr 
 to the top of the stack whenever possible?  The only use case that seems to 
 not fit that today seems to be client-side job updates, which we could ignore 
 since it's scheduled for removal.

| Perhaps we should take the approach of limiting use of stdout/stderr to the 
top of the stack whenever possible?

Agree, that would make sense. There are plenty of examples where that happens. 
E.g. compare [1] and [2]. The first one has redundant print_err() and will 
result in duplicate messages. The second one (used as example above) only 
loggged by the CommineLine handler. This diff addresses a problem where a 
redundant incomplete message is logged after unsuccessful scheduler call. I 
suggest we tackle the [1] separately.

[1] - 
https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L342-L344
[2] - 
https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L368-L370


- Maxim


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


On Dec. 9, 2014, 10:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28876/
 ---
 
 (Updated Dec. 9, 2014, 10:32 p.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-965
 https://issues.apache.org/jira/browse/AURORA-965
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Added a new error type to raise when errors are logged explicitly.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 c2eb89cae536838ac4dd46b0125a248d84f6e54c 
   src/main/python/apache/aurora/client/cli/context.py 
 ad27eb5674fb85c5d3a26a014349abdea4fa2d64 
   src/test/python/apache/aurora/client/cli/test_update.py 
 1f061a39279bf5ef9d4e7279016bf07e164014bb 
 
 Diff: https://reviews.apache.org/r/28876/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli:all
 
 Vagrant before:
 
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 Error executing command: Job creation failed due to error:
 ```
 
 Vagrant after:
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Review Request 28883: Fixing @Timed method visibility.

2014-12-09 Thread Maxim Khutornenko

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

Review request for Aurora and Bill Farner.


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


Repository: aurora


Description
---

Fixing @Timed method visibility.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
ead9d28100673440168a32d114ecaa15874978a6 

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


Testing
---

Tested in vagrant:
```
task_schedule_attempt_events 5
task_schedule_attempt_events_per_sec 0.9989254079902053
task_schedule_attempt_locked_events 5
task_schedule_attempt_locked_events_per_sec 1.0019749236357087
task_schedule_attempt_locked_nanos_per_event 1570156.6526848162
task_schedule_attempt_locked_nanos_total 45453749
task_schedule_attempt_locked_nanos_total_per_sec 1573257.5921699686
task_schedule_attempt_nanos_per_event 1759287.885810068
task_schedule_attempt_nanos_total 48291560
task_schedule_attempt_nanos_total_per_sec 1757397.369105048
```


Thanks,

Maxim Khutornenko



Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-09 Thread Maxim Khutornenko


 On Dec. 10, 2014, 1:09 a.m., Kevin Sweeney wrote:
  src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java, lines 
  29-32
  https://reviews.apache.org/r/28710/diff/4/?file=784251#file784251line29
 
  What does the main get us here? Isn't the gradle plugin wiring this up?

Good point. I used it to run benchmarks from command line but given the command 
line execution is rather tedious with all jmh flags passed into it, it's 
cleaner to support only one way via gradle. Dropped.


- Maxim


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


On Dec. 6, 2014, 12:33 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28710/
 ---
 
 (Updated Dec. 6, 2014, 12:33 a.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This RB is superseding the https://reviews.apache.org/r/28474/.
 
 
 I have spent some time researching the available microbenchmark frameworks 
 and JMH [1] came as a clear winner:
 - Active development trail [2]
 - Advanced featureset and built-in optimizations improving accuracy and 
 consistency [3]
 - Well documented set of examples [4]
 - Large community experience and collective wisdom. 
 
 
 This RB adds gradle support for running JMH benchmarks and is relying on JMH 
 gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.
 
 [1] - http://openjdk.java.net/projects/code-tools/jmh/
 [2] - http://hg.openjdk.java.net/code-tools/jmh/ 
 [3] - 
 https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
 [4] - 
 http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
 [5] - https://github.com/melix/jmh-gradle-plugin
 
 
 Diffs
 -
 
   build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
   config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
   src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28710/diff/
 
 
 Testing
 ---
 
 $ ./gradlew jmh
 
 Sample results generated:
 
 ```
 # VM invoker: 
 /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
 # VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
 -Duser.variant
 # Warmup: 1 iterations, 1 s each
 # Measurement: 3 iterations, 1 s each
 # Timeout: 10 min per iteration
 # Threads: 1 thread, will synchronize iterations
 # Benchmark mode: Throughput, ops/time
 # Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example
 
 # Run progress: 0.00% complete, ETA 00:00:04
 # Fork: 1 of 1
 # Warmup Iteration   1: 3156839103.911 ops/s
 Iteration   1: 544897.411 ops/s
 Iteration   2: 3357230627.218 ops/s
 Iteration   3: 3461073727.560 ops/s
 
 
 Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
   Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
 3461073727.560), stdev = 67833135.714
   Confidence interval (99.9%): [2146420835.212, 4621478666.247]
 
 
 # Run complete. Total time: 00:00:05
 
 Benchmark  Mode  Samples   Score  
   Error  Units
 o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
 1237528915.517  ops/s
 
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-09 Thread Maxim Khutornenko

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

(Updated Dec. 10, 2014, 1:22 a.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

CR comments.


Repository: aurora


Description
---

This RB is superseding the https://reviews.apache.org/r/28474/.


I have spent some time researching the available microbenchmark frameworks and 
JMH [1] came as a clear winner:
- Active development trail [2]
- Advanced featureset and built-in optimizations improving accuracy and 
consistency [3]
- Well documented set of examples [4]
- Large community experience and collective wisdom. 


This RB adds gradle support for running JMH benchmarks and is relying on JMH 
gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.

[1] - http://openjdk.java.net/projects/code-tools/jmh/
[2] - http://hg.openjdk.java.net/code-tools/jmh/ 
[3] - 
https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
[4] - 
http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
[5] - https://github.com/melix/jmh-gradle-plugin


Diffs (updated)
-

  build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
  config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
  src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java PRE-CREATION 

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


Testing
---

$ ./gradlew jmh

Sample results generated:

```
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
# VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 1 s each
# Measurement: 3 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example

# Run progress: 0.00% complete, ETA 00:00:04
# Fork: 1 of 1
# Warmup Iteration   1: 3156839103.911 ops/s
Iteration   1: 544897.411 ops/s
Iteration   2: 3357230627.218 ops/s
Iteration   3: 3461073727.560 ops/s


Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
  Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
3461073727.560), stdev = 67833135.714
  Confidence interval (99.9%): [2146420835.212, 4621478666.247]


# Run complete. Total time: 00:00:05

Benchmark  Mode  Samples   Score
Error  Units
o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
1237528915.517  ops/s

```


Thanks,

Maxim Khutornenko



Re: Review Request 28876: Suppressing redundant client command error messaging.

2014-12-09 Thread Maxim Khutornenko


 On Dec. 9, 2014, 11:29 p.m., Zameer Manji wrote:
  src/main/python/apache/aurora/client/cli/__init__.py, line 384
  https://reviews.apache.org/r/28876/diff/1/?file=787343#file787343line384
 
  This solution seems to be papering over the problem we have with output 
  in the client.
  
  Instead of creating a new type of exception can we just prevent the 
  double printing in general?
 
 Maxim Khutornenko wrote:
 Not sure I buy it. This `print_err()` is needed when a CommandError is 
 raised to bail out due to some internal problem (i.e. not related to 
 scheduler call and not routed through context.check_and_log_response). The 
 fact that the same error type is used for both is exactly the reason we have 
 these redundant messages. There are plenty of legitimate cases where the 
 error needs to be logged. Consider this example:
 ```
 $ aurora2 job kill devcluster/www-data/prod/hello
 Error executing command: The instances list cannot be omitted in a kill 
 command!; use killall to kill all instances
 ```
 
 Bill Farner wrote:
 Part of the problem here is that logging to stdout/stderr happens 
 throughout the stack.  This seems to inevitably lead towards redundant 
 output.  Perhaps we should take the approach of limiting use of stdout/stderr 
 to the top of the stack whenever possible?  The only use case that seems to 
 not fit that today seems to be client-side job updates, which we could ignore 
 since it's scheduled for removal.
 
 Maxim Khutornenko wrote:
 | Perhaps we should take the approach of limiting use of stdout/stderr to 
 the top of the stack whenever possible?
 
 Agree, that would make sense. There are plenty of examples where that 
 happens. E.g. compare [1] and [2]. The first one has redundant print_err() 
 and will result in duplicate messages. The second one (used as example above) 
 only loggged by the CommineLine handler. This diff addresses a problem where 
 a redundant incomplete message is logged after unsuccessful scheduler call. I 
 suggest we tackle the [1] separately.
 
 [1] - 
 https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L342-L344
 [2] - 
 https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/client/cli/jobs.py#L368-L370
 
 Bill Farner wrote:
 Going back to Zameer's comment, though, maybe `check_and_log_response` 
 should refrain from calling `print_err`?  Seems like the receiving end of 
 `CommandError` should be responsible for presenting the error.

I am not sure what it really buys us. Right now, the scheduler response is 
entirely handled within the check_and_log_response that does centralized 
logging to both stdout and stderr. IMO, delegating just stderr handling 
elsewhere creates more ambiguity and is not solving any additional problems.


- Maxim


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


On Dec. 9, 2014, 10:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28876/
 ---
 
 (Updated Dec. 9, 2014, 10:32 p.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-965
 https://issues.apache.org/jira/browse/AURORA-965
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Added a new error type to raise when errors are logged explicitly.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 c2eb89cae536838ac4dd46b0125a248d84f6e54c 
   src/main/python/apache/aurora/client/cli/context.py 
 ad27eb5674fb85c5d3a26a014349abdea4fa2d64 
   src/test/python/apache/aurora/client/cli/test_update.py 
 1f061a39279bf5ef9d4e7279016bf07e164014bb 
 
 Diff: https://reviews.apache.org/r/28876/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client/cli:all
 
 Vagrant before:
 
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 Error executing command: Job creation failed due to error:
 ```
 
 Vagrant after:
 ```
 $ aurora2 job create devcluster/www-data/prod/hello 
 aurora/examples/jobs/hello_world.aurora 
  INFO] Creating job hello
 Job creation failed due to error:
   Job already exists: www-data/prod/hello
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Review Request 28806: More logging in MaintenanceController.

2014-12-08 Thread Maxim Khutornenko

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

Review request for Aurora and Bill Farner.


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


Repository: aurora


Description
---

More logging in MaintenanceController.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/state/MaintenanceController.java 
8e6f4e7c18df4bac4dab747f05803e8e25b43cda 

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


Testing
---

./gradlew -Pq build


Thanks,

Maxim Khutornenko



Re: Review Request 28742: Simplify logging in the client.

2014-12-08 Thread Maxim Khutornenko

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



src/main/python/apache/aurora/client/cli/client.py
https://reviews.apache.org/r/28742/#comment106906

Is there a test for this?



src/main/python/apache/aurora/client/cli/context.py
https://reviews.apache.org/r/28742/#comment106904

This can now be simplified with `base.combine_messages(resp)`.


- Maxim Khutornenko


On Dec. 8, 2014, 7:58 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28742/
 ---
 
 (Updated Dec. 8, 2014, 7:58 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-919
 https://issues.apache.org/jira/browse/AURORA-919
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This patch makes multiple changes to simplify the logging done in the Aurora 
 client:
 1. Remove the TRANSCRIPT log level and replaced all instances with the 
 standard Python DEBUG level.
 2. Remove the custom aurora_client logger. This logger was designed to give 
 each invocation of the client a unique id and record the username of the user 
 with the intention that a hook could take this information and ship it to the 
 cluster administer. However a hook could capture logs by adding a handler to 
 the root log handler and generate a unique id itself.
 3. Remove the 'print_log' method of the context and replaced all callers with 
 the standard python logging facilities.
 4. Removed duplicate printing/logging messages by just printing the 
 information to the user.
 5. Removed the custom PlainFormatter implementation and replaced it with 
 Python's default formatter.
 6. Replaced the --verbose-logging and --logging-level flags with a single 
 --verbose/-v flag which enables DEBUG logging. Without this flag the user 
 sees INFO and up.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/BUILD 
 ebe681a0d1735b7cc695dc3b7a14c4292d87ae32 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/main/python/apache/aurora/client/cli/client.py 
 0cb69448cd24372067ac845eca5862bc3d3a46a9 
   src/main/python/apache/aurora/client/cli/command_hooks.py 
 aa850bf941bede1d3bd8aae4811cb094ba77965f 
   src/main/python/apache/aurora/client/cli/context.py 
 51c7d24dca664e476e62f1864d095416dfab70e4 
   src/main/python/apache/aurora/client/cli/jobs.py 
 8f349c09637c16e2499e85f2dc96eb7ccffd0aaf 
   src/main/python/apache/aurora/client/cli/logsetup.py 
 55d99c42f643910db0bf3c24022596383e160276 
   src/main/python/apache/aurora/client/cli/task.py 
 91175facdc8c9fd59ab66781f86ee8b5940a 
   src/test/python/apache/aurora/client/cli/BUILD 
 e1f9ebf96774b8f5c75de8570c6ba87d953ab649 
   src/test/python/apache/aurora/client/cli/test_logging.py 
 6285fbb07442291c2dc4096e68eb285c98994097 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
   src/test/python/apache/aurora/client/cli/test_task.py 
 c69a624ec7063973d365846f7df3516047ceeb68 
 
 Diff: https://reviews.apache.org/r/28742/diff/
 
 
 Testing
 ---
 
 ./pants ./src/test/python/apache/aurora::
 
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 config list 
 ./aurora/examples/jobs/hello_world.aurora
 jobs=[devcluster/www-data/prod/hello]
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job create 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Creating job hello
  INFO] Checking status of devcluster/www-data/prod/hello
 job create succeeded: job 
 url=http://vagrant-ubuntu-trusty-64:8081/scheduler/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job list devcluster/*
  INFO] Retrieving jobs for role None
 devcluster/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job update 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Updating job: hello
  INFO] Instances to update: [0, 1]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Examining instance: 0
  INFO] Skipping unchanged instance: 0
  INFO] Examining instance: 1
  INFO] Adding instance: 1
  INFO] Added: 1
  INFO] Watching instances: [1]
  INFO] Instance 1 was not reported healthy within 60 seconds
  INFO] Failed instances: set([1])
  WARN] Not restarting failed instances [1], which exceeded maximum allowed 
 instance failure limit of 0
 ERROR] 1 failed instances observed, maximum allowed is 0
 ERROR] 1 instance failures for instance 1, maximum allowed is 0
  INFO] Reverting update for: [1, 0]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Reverting instance: 1
  INFO] Examining instance: 1
  INFO] Killing instance: 1
  INFO] Killed

Review Request 28811: Improving logging experience in admin drain_hosts.

2014-12-08 Thread Maxim Khutornenko

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

Review request for Aurora and Bill Farner.


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


Repository: aurora


Description
---

Improving logging experience in admin drain_hosts.


Diffs
-

  src/main/python/apache/aurora/admin/host_maintenance.py 
bff8afd2b52fdf3977f681a73c97000a38773498 
  src/test/python/apache/aurora/admin/test_host_maintenance.py 
4b8072c0349a9b0905ebb249ed97c7dfe8e8b1de 

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


Testing
---

./pants src/test/python/apache/aurora/admin:host_maintenance


Thanks,

Maxim Khutornenko



Re: Review Request 28811: Improving logging experience in admin drain_hosts.

2014-12-08 Thread Maxim Khutornenko


 On Dec. 8, 2014, 9:21 p.m., Bill Farner wrote:
  src/main/python/apache/aurora/admin/host_maintenance.py, line 85
  https://reviews.apache.org/r/28811/diff/1/?file=785748#file785748line85
 
  Should this be:
  
  `self.check_if_drained(drainable_hostnames)`

  It seems strange that if we're watching 2 hosts, and 1 moves to 
  DRAINED, we keep querying for its state.
  
  Coupled with the logging change in this diff, it appears that you'll 
  keep logging the same hostnames over and over.

Not sure I understand. The `not_drained_hostnames =` assignment takes care of 
progressively reducing the logged hostset, so a DRAINED host will never show up 
in any of the subsequent iterations.


 On Dec. 8, 2014, 9:21 p.m., Bill Farner wrote:
  src/main/python/apache/aurora/admin/host_maintenance.py, line 61
  https://reviews.apache.org/r/28811/diff/1/?file=785748#file785748line61
 
  Can you elaborate why this is an improvement?  AFAICT the former 
  messaging was more accurate - we print out the hosts that you're waiting 
  for, and will be queried/tracked.
  
  This change might make sense if we did _not_ do the initial DRAINED 
  filtering here, and allow the caller to report that these hosts are ready.
  
  Finally - you should consider inlining this function - there's hardly 
  any behavior here, and there's only one caller.

The current log placement may generate an empty message when draining is done 
faster than the initial wait interval, giving a somewhat confusing user 
experience. The reordering here makes sure a user sees the initial draining 
batch in the log at least once. I am fine with inlining if it makes things 
easier to read.


- Maxim


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


On Dec. 8, 2014, 9:13 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28811/
 ---
 
 (Updated Dec. 8, 2014, 9:13 p.m.)
 
 
 Review request for Aurora and Bill Farner.
 
 
 Bugs: AURORA-943
 https://issues.apache.org/jira/browse/AURORA-943
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Improving logging experience in admin drain_hosts.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/admin/host_maintenance.py 
 bff8afd2b52fdf3977f681a73c97000a38773498 
   src/test/python/apache/aurora/admin/test_host_maintenance.py 
 4b8072c0349a9b0905ebb249ed97c7dfe8e8b1de 
 
 Diff: https://reviews.apache.org/r/28811/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/admin:host_maintenance
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28811: Improving logging experience in admin drain_hosts.

2014-12-08 Thread Maxim Khutornenko


 On Dec. 8, 2014, 9:21 p.m., Bill Farner wrote:
  src/main/python/apache/aurora/admin/host_maintenance.py, line 85
  https://reviews.apache.org/r/28811/diff/1/?file=785748#file785748line85
 
  Should this be:
  
  `self.check_if_drained(drainable_hostnames)`

  It seems strange that if we're watching 2 hosts, and 1 moves to 
  DRAINED, we keep querying for its state.
  
  Coupled with the logging change in this diff, it appears that you'll 
  keep logging the same hostnames over and over.
 
 Maxim Khutornenko wrote:
 Not sure I understand. The `not_drained_hostnames =` assignment takes 
 care of progressively reducing the logged hostset, so a DRAINED host will 
 never show up in any of the subsequent iterations.

Got it now, you probably meant `not_drained_hostnames` as a parameter there. 
Makes sense.


- Maxim


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


On Dec. 8, 2014, 9:13 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28811/
 ---
 
 (Updated Dec. 8, 2014, 9:13 p.m.)
 
 
 Review request for Aurora and Bill Farner.
 
 
 Bugs: AURORA-943
 https://issues.apache.org/jira/browse/AURORA-943
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Improving logging experience in admin drain_hosts.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/admin/host_maintenance.py 
 bff8afd2b52fdf3977f681a73c97000a38773498 
   src/test/python/apache/aurora/admin/test_host_maintenance.py 
 4b8072c0349a9b0905ebb249ed97c7dfe8e8b1de 
 
 Diff: https://reviews.apache.org/r/28811/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/admin:host_maintenance
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28811: Improving logging experience in admin drain_hosts.

2014-12-08 Thread Maxim Khutornenko

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

(Updated Dec. 8, 2014, 10:43 p.m.)


Review request for Aurora and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Improving logging experience in admin drain_hosts.


Diffs (updated)
-

  src/main/python/apache/aurora/admin/host_maintenance.py 
bff8afd2b52fdf3977f681a73c97000a38773498 
  src/test/python/apache/aurora/admin/test_host_maintenance.py 
4b8072c0349a9b0905ebb249ed97c7dfe8e8b1de 

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


Testing
---

./pants src/test/python/apache/aurora/admin:host_maintenance


Thanks,

Maxim Khutornenko



Re: Review Request 28617: Implemented offer filtering for tasks with static vetoes.

2014-12-08 Thread Maxim Khutornenko


 On Dec. 8, 2014, 7:29 p.m., Kevin Sweeney wrote:
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java, 
  line 102
  https://reviews.apache.org/r/28617/diff/2/?file=784162#file784162line102
 
  Can you add this as a member to the Veto interface instead? This will 
  ensure we don't add new Veto types without updating this map.
  
  Like
  
  ```java
  interface Veto {
VetoGroup getVetoGroup();
  }
  ```

There is no Veto interface and I am hesitant to create one just for this 
method. I have moved the group assignment into the VetoType instead. That also 
helped to get rid of a null check code not reachable from unit tests.


 On Dec. 8, 2014, 7:29 p.m., Kevin Sweeney wrote:
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java, 
  line 181
  https://reviews.apache.org/r/28617/diff/2/?file=784162#file784162line181
 
  If you follow the comment above this block becomes unnecessary.

Gone.


- Maxim


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


On Dec. 5, 2014, 10:57 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28617/
 ---
 
 (Updated Dec. 5, 2014, 10:57 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Bugs: AURORA-909
 https://issues.apache.org/jira/browse/AURORA-909
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Modified the task offer/task matching logic to skip offer matching for tasks 
 previously vetoed statically.
 
 Preliminary testing in vagrant (see pictures below) shows close to 50% 
 improvement in task scheduling performance.
 
 Update:
 Testing with JMH (https://reviews.apache.org/r/28710/ and 
 https://reviews.apache.org/r/28731/) shows over 97% better perf:
 
 ```
 Master with cluster fillup 0.9:
 Benchmark 
Mode  SamplesScoreError  Units
 o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example   
avgt  100  8291046.074 ± 145251.995  ns/op
 o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example 
avgt  100  7522269.050 ± 142446.265  ns/op
 
 This RB with cluster fillup 0.9:
 Benchmark 
Mode  Samples   Score  Error  Units
 o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example   
avgt  100  204171.046 ± 3800.124  ns/op
 o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example 
avgt  100  215854.129 ± 8959.851  ns/op
 ```
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 f017cdd26ca40138a7e141f21613ed567314c399 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 f66383830140e5eaba436f35ebb5192eee65947a 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 ead9d28100673440168a32d114ecaa15874978a6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c2a342ce07bfb223193886038761f0da5230135d 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 1cb56f19c331508a1585077e9c4a98f52aac343b 
   src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java 
 e1c29747c9854cf75bf63f6f085cf40ca68989af 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 4e7efb3c1214c3d193afd61f162713490eb8effb 
   src/test/java/org/apache/aurora/scheduler/async/OfferQueueImplTest.java 
 4cf602ad32b972c18eb5a81e9b2f59c67859bdb2 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
 5647349854a5e04de749c4d809684a0066d4da06 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
 6cc13231560996b144101eba36577f49017aba06 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  265c38d20136210e7639ac8ea915d307a4b72949 
   src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java 
 411a55a8d85f60bb2703468f2d69b64b2736eee4 
 
 Diff: https://reviews.apache.org/r/28617/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 Tested in vagrant
 
 
 File Attachments
 
 
 NoStaticVetoFiltering.png
   
 https://reviews.apache.org/media/uploaded/files/2014/12/03/7945c60b-4135-4016-a9bf-8d4815a4a573__NoStaticVetoFiltering.png
 StaticVetoFiltering.png
   
 https://reviews.apache.org/media/uploaded/files/2014/12/03/2f73b94a-5ba9-43b6-922e-e9e4ec18d0bb__StaticVetoFiltering.png
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28617: Implemented offer filtering for tasks with static vetoes.

2014-12-08 Thread Maxim Khutornenko

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

(Updated Dec. 8, 2014, 10:57 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Modified the task offer/task matching logic to skip offer matching for tasks 
previously vetoed statically.

Preliminary testing in vagrant (see pictures below) shows close to 50% 
improvement in task scheduling performance.

Update:
Testing with JMH (https://reviews.apache.org/r/28710/ and 
https://reviews.apache.org/r/28731/) shows over 97% better perf:

```
Master with cluster fillup 0.9:
Benchmark   
 Mode  SamplesScoreError  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  8291046.074 ± 145251.995  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  7522269.050 ± 142446.265  ns/op

This RB with cluster fillup 0.9:
Benchmark   
 Mode  Samples   Score  Error  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  204171.046 ± 3800.124  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  215854.129 ± 8959.851  ns/op
```


Diffs (updated)
-

  src/main/java/org/apache/aurora/scheduler/TaskVars.java 
f017cdd26ca40138a7e141f21613ed567314c399 
  src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
f66383830140e5eaba436f35ebb5192eee65947a 
  src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
ead9d28100673440168a32d114ecaa15874978a6 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
c2a342ce07bfb223193886038761f0da5230135d 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
1cb56f19c331508a1585077e9c4a98f52aac343b 
  src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java 
e1c29747c9854cf75bf63f6f085cf40ca68989af 
  src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
4e7efb3c1214c3d193afd61f162713490eb8effb 
  src/test/java/org/apache/aurora/scheduler/async/OfferQueueImplTest.java 
4cf602ad32b972c18eb5a81e9b2f59c67859bdb2 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
5647349854a5e04de749c4d809684a0066d4da06 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
6cc13231560996b144101eba36577f49017aba06 
  
src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java 
265c38d20136210e7639ac8ea915d307a4b72949 
  src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java 
411a55a8d85f60bb2703468f2d69b64b2736eee4 

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


Testing
---

./gradlew -Pq build

Tested in vagrant


File Attachments


NoStaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/7945c60b-4135-4016-a9bf-8d4815a4a573__NoStaticVetoFiltering.png
StaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/2f73b94a-5ba9-43b6-922e-e9e4ec18d0bb__StaticVetoFiltering.png


Thanks,

Maxim Khutornenko



Re: Review Request 28742: Simplify logging in the client.

2014-12-08 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 8, 2014, 11:18 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28742/
 ---
 
 (Updated Dec. 8, 2014, 11:18 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-919
 https://issues.apache.org/jira/browse/AURORA-919
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This patch makes multiple changes to simplify the logging done in the Aurora 
 client:
 1. Remove the TRANSCRIPT log level and replaced all instances with the 
 standard Python DEBUG level.
 2. Remove the custom aurora_client logger. This logger was designed to give 
 each invocation of the client a unique id and record the username of the user 
 with the intention that a hook could take this information and ship it to the 
 cluster administer. However a hook could capture logs by adding a handler to 
 the root log handler and generate a unique id itself.
 3. Remove the 'print_log' method of the context and replaced all callers with 
 the standard python logging facilities.
 4. Removed duplicate printing/logging messages by just printing the 
 information to the user.
 5. Removed the custom PlainFormatter implementation and replaced it with 
 Python's default formatter.
 6. Replaced the --verbose-logging and --logging-level flags with a single 
 --verbose/-v flag which enables DEBUG logging. Without this flag the user 
 sees INFO and up.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/BUILD 
 ebe681a0d1735b7cc695dc3b7a14c4292d87ae32 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/main/python/apache/aurora/client/cli/client.py 
 0cb69448cd24372067ac845eca5862bc3d3a46a9 
   src/main/python/apache/aurora/client/cli/command_hooks.py 
 aa850bf941bede1d3bd8aae4811cb094ba77965f 
   src/main/python/apache/aurora/client/cli/context.py 
 51c7d24dca664e476e62f1864d095416dfab70e4 
   src/main/python/apache/aurora/client/cli/jobs.py 
 8f349c09637c16e2499e85f2dc96eb7ccffd0aaf 
   src/main/python/apache/aurora/client/cli/logsetup.py 
 55d99c42f643910db0bf3c24022596383e160276 
   src/main/python/apache/aurora/client/cli/task.py 
 91175facdc8c9fd59ab66781f86ee8b5940a 
   src/test/python/apache/aurora/client/cli/BUILD 
 e1f9ebf96774b8f5c75de8570c6ba87d953ab649 
   src/test/python/apache/aurora/client/cli/test_client.py PRE-CREATION 
   src/test/python/apache/aurora/client/cli/test_logging.py 
 6285fbb07442291c2dc4096e68eb285c98994097 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
   src/test/python/apache/aurora/client/cli/test_task.py 
 c69a624ec7063973d365846f7df3516047ceeb68 
 
 Diff: https://reviews.apache.org/r/28742/diff/
 
 
 Testing
 ---
 
 ./pants ./src/test/python/apache/aurora::
 
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 config list 
 ./aurora/examples/jobs/hello_world.aurora
 jobs=[devcluster/www-data/prod/hello]
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job create 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Creating job hello
  INFO] Checking status of devcluster/www-data/prod/hello
 job create succeeded: job 
 url=http://vagrant-ubuntu-trusty-64:8081/scheduler/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job list devcluster/*
  INFO] Retrieving jobs for role None
 devcluster/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job update 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Updating job: hello
  INFO] Instances to update: [0, 1]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Examining instance: 0
  INFO] Skipping unchanged instance: 0
  INFO] Examining instance: 1
  INFO] Adding instance: 1
  INFO] Added: 1
  INFO] Watching instances: [1]
  INFO] Instance 1 was not reported healthy within 60 seconds
  INFO] Failed instances: set([1])
  WARN] Not restarting failed instances [1], which exceeded maximum allowed 
 instance failure limit of 0
 ERROR] 1 failed instances observed, maximum allowed is 0
 ERROR] 1 instance failures for instance 1, maximum allowed is 0
  INFO] Reverting update for: [1, 0]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Reverting instance: 1
  INFO] Examining instance: 1
  INFO] Killing instance: 1
  INFO] Killed: 1
  INFO] Reverting instance: 0
  INFO] Examining instance: 0
  INFO] Skipping unchanged instance: 0
  WARN] Update failures threshold reached
 Update failed due to error:
   Update reverted
 Error executing

Re: Review Request 28742: Simplify logging in the client.

2014-12-08 Thread Maxim Khutornenko

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


On master now.

- Maxim Khutornenko


On Dec. 8, 2014, 11:18 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28742/
 ---
 
 (Updated Dec. 8, 2014, 11:18 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-919
 https://issues.apache.org/jira/browse/AURORA-919
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This patch makes multiple changes to simplify the logging done in the Aurora 
 client:
 1. Remove the TRANSCRIPT log level and replaced all instances with the 
 standard Python DEBUG level.
 2. Remove the custom aurora_client logger. This logger was designed to give 
 each invocation of the client a unique id and record the username of the user 
 with the intention that a hook could take this information and ship it to the 
 cluster administer. However a hook could capture logs by adding a handler to 
 the root log handler and generate a unique id itself.
 3. Remove the 'print_log' method of the context and replaced all callers with 
 the standard python logging facilities.
 4. Removed duplicate printing/logging messages by just printing the 
 information to the user.
 5. Removed the custom PlainFormatter implementation and replaced it with 
 Python's default formatter.
 6. Replaced the --verbose-logging and --logging-level flags with a single 
 --verbose/-v flag which enables DEBUG logging. Without this flag the user 
 sees INFO and up.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/BUILD 
 ebe681a0d1735b7cc695dc3b7a14c4292d87ae32 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/main/python/apache/aurora/client/cli/client.py 
 0cb69448cd24372067ac845eca5862bc3d3a46a9 
   src/main/python/apache/aurora/client/cli/command_hooks.py 
 aa850bf941bede1d3bd8aae4811cb094ba77965f 
   src/main/python/apache/aurora/client/cli/context.py 
 51c7d24dca664e476e62f1864d095416dfab70e4 
   src/main/python/apache/aurora/client/cli/jobs.py 
 8f349c09637c16e2499e85f2dc96eb7ccffd0aaf 
   src/main/python/apache/aurora/client/cli/logsetup.py 
 55d99c42f643910db0bf3c24022596383e160276 
   src/main/python/apache/aurora/client/cli/task.py 
 91175facdc8c9fd59ab66781f86ee8b5940a 
   src/test/python/apache/aurora/client/cli/BUILD 
 e1f9ebf96774b8f5c75de8570c6ba87d953ab649 
   src/test/python/apache/aurora/client/cli/test_client.py PRE-CREATION 
   src/test/python/apache/aurora/client/cli/test_logging.py 
 6285fbb07442291c2dc4096e68eb285c98994097 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
   src/test/python/apache/aurora/client/cli/test_task.py 
 c69a624ec7063973d365846f7df3516047ceeb68 
 
 Diff: https://reviews.apache.org/r/28742/diff/
 
 
 Testing
 ---
 
 ./pants ./src/test/python/apache/aurora::
 
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 config list 
 ./aurora/examples/jobs/hello_world.aurora
 jobs=[devcluster/www-data/prod/hello]
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job create 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Creating job hello
  INFO] Checking status of devcluster/www-data/prod/hello
 job create succeeded: job 
 url=http://vagrant-ubuntu-trusty-64:8081/scheduler/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job list devcluster/*
  INFO] Retrieving jobs for role None
 devcluster/www-data/prod/hello
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora2 job update 
 devcluster/www-data/prod/hello ./aurora/examples/jobs/hello_world.aurora
  INFO] Updating job: hello
  INFO] Instances to update: [0, 1]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Examining instance: 0
  INFO] Skipping unchanged instance: 0
  INFO] Examining instance: 1
  INFO] Adding instance: 1
  INFO] Added: 1
  INFO] Watching instances: [1]
  INFO] Instance 1 was not reported healthy within 60 seconds
  INFO] Failed instances: set([1])
  WARN] Not restarting failed instances [1], which exceeded maximum allowed 
 instance failure limit of 0
 ERROR] 1 failed instances observed, maximum allowed is 0
 ERROR] 1 instance failures for instance 1, maximum allowed is 0
  INFO] Reverting update for: [1, 0]
  INFO] Processing in parallel with 1 worker thread(s)
  INFO] Reverting instance: 1
  INFO] Examining instance: 1
  INFO] Killing instance: 1
  INFO] Killed: 1
  INFO] Reverting instance: 0
  INFO] Examining instance: 0
  INFO] Skipping unchanged instance: 0
  WARN] Update failures threshold reached
 Update failed due to error:
   Update reverted
 Error executing

Review Request 28831: Changing the default --batch-size to 1.

2014-12-08 Thread Maxim Khutornenko

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

Review request for Aurora and Bill Farner.


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


Repository: aurora


Description
---

Also, cleaned up kill command tests a bit.


Diffs
-

  src/main/python/apache/aurora/client/cli/options.py 
e844cf340583b631ce194352f403bbaec71655b7 
  src/test/python/apache/aurora/client/cli/test_kill.py 
1eda72af4c19831ae27733f506858e67772b2075 
  src/test/python/apache/aurora/client/cli/util.py 
67d7eaa6eff4e1dbaaa485166e084812a4f04074 

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


Testing
---

./pants src/test/python/apache/aurora/client/cli:all


Thanks,

Maxim Khutornenko



Re: Review Request 28738: Remove unused DefaultServlet subclass.

2014-12-05 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 5, 2014, 4:06 a.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28738/
 ---
 
 (Updated Dec. 5, 2014, 4:06 a.m.)
 
 
 Review request for Aurora and Kevin Sweeney.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Remove unused DefaultServlet subclass.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
 424859867d7bd1aafefe406f455b831246c1cca5 
 
 Diff: https://reviews.apache.org/r/28738/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-05 Thread Maxim Khutornenko

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

(Updated Dec. 5, 2014, 6:32 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

Rebased.


Repository: aurora


Description
---

This RB is superseding the https://reviews.apache.org/r/28474/.


I have spent some time researching the available microbenchmark frameworks and 
JMH [1] came as a clear winner:
- Active development trail [2]
- Advanced featureset and built-in optimizations improving accuracy and 
consistency [3]
- Well documented set of examples [4]
- Large community experience and collective wisdom. 


This RB adds gradle support for running JMH benchmarks and is relying on JMH 
gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.

[1] - http://openjdk.java.net/projects/code-tools/jmh/
[2] - http://hg.openjdk.java.net/code-tools/jmh/ 
[3] - 
https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
[4] - 
http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
[5] - https://github.com/melix/jmh-gradle-plugin


Diffs (updated)
-

  build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
  config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
  src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java PRE-CREATION 

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


Testing
---

$ ./gradlew jmh

Sample results generated:

```
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
# VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 1 s each
# Measurement: 3 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example

# Run progress: 0.00% complete, ETA 00:00:04
# Fork: 1 of 1
# Warmup Iteration   1: 3156839103.911 ops/s
Iteration   1: 544897.411 ops/s
Iteration   2: 3357230627.218 ops/s
Iteration   3: 3461073727.560 ops/s


Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
  Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
3461073727.560), stdev = 67833135.714
  Confidence interval (99.9%): [2146420835.212, 4621478666.247]


# Run complete. Total time: 00:00:05

Benchmark  Mode  Samples   Score
Error  Units
o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
1237528915.517  ops/s

```


Thanks,

Maxim Khutornenko



Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-05 Thread Maxim Khutornenko


 On Dec. 5, 2014, 8:06 p.m., Bill Farner wrote:
  Not to bikeshed, but do either of you have a sense for what it would take 
  to put the benchmarking code into a gradle subproject?  My sense is that 
  would avoid further complicating the root build.gradle, but i'm not 
  familiar enough with gradle to know what, if any, hurdles that would 
  present.

There is not much to hide in a subproject as all you see here is configuring 
the plugin to run with our gradle. I don't see any sane way of hiding it in a 
subproject short of reimplementing the plugin ourselves.


- Maxim


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


On Dec. 5, 2014, 6:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28710/
 ---
 
 (Updated Dec. 5, 2014, 6:32 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This RB is superseding the https://reviews.apache.org/r/28474/.
 
 
 I have spent some time researching the available microbenchmark frameworks 
 and JMH [1] came as a clear winner:
 - Active development trail [2]
 - Advanced featureset and built-in optimizations improving accuracy and 
 consistency [3]
 - Well documented set of examples [4]
 - Large community experience and collective wisdom. 
 
 
 This RB adds gradle support for running JMH benchmarks and is relying on JMH 
 gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.
 
 [1] - http://openjdk.java.net/projects/code-tools/jmh/
 [2] - http://hg.openjdk.java.net/code-tools/jmh/ 
 [3] - 
 https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
 [4] - 
 http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
 [5] - https://github.com/melix/jmh-gradle-plugin
 
 
 Diffs
 -
 
   build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
   config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
   src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28710/diff/
 
 
 Testing
 ---
 
 $ ./gradlew jmh
 
 Sample results generated:
 
 ```
 # VM invoker: 
 /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
 # VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
 -Duser.variant
 # Warmup: 1 iterations, 1 s each
 # Measurement: 3 iterations, 1 s each
 # Timeout: 10 min per iteration
 # Threads: 1 thread, will synchronize iterations
 # Benchmark mode: Throughput, ops/time
 # Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example
 
 # Run progress: 0.00% complete, ETA 00:00:04
 # Fork: 1 of 1
 # Warmup Iteration   1: 3156839103.911 ops/s
 Iteration   1: 544897.411 ops/s
 Iteration   2: 3357230627.218 ops/s
 Iteration   3: 3461073727.560 ops/s
 
 
 Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
   Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
 3461073727.560), stdev = 67833135.714
   Confidence interval (99.9%): [2146420835.212, 4621478666.247]
 
 
 # Run complete. Total time: 00:00:05
 
 Benchmark  Mode  Samples   Score  
   Error  Units
 o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
 1237528915.517  ops/s
 
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28771: Don't fall back to old command syntax in the new client.

2014-12-05 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 5, 2014, 9:12 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28771/
 ---
 
 (Updated Dec. 5, 2014, 9:12 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-782
 https://issues.apache.org/jira/browse/AURORA-782
 
 
 Repository: aurora
 
 
 Description
 ---
 
 The diff appears like a large delta to `cli/client.py`, but it is in fact a 
 pure `git mv` of standalone_client.py to client.py, since the qualification 
 no longer makes sense.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/BUILD 
 8d34bf71a225210f1fef8b5a69bc9f14b49d17bb 
   src/main/python/apache/aurora/client/cli/client.py 
 a1df788adf2c8066d207e6b70d7694f6975b8edd 
   src/main/python/apache/aurora/client/cli/standalone_client.py 
 93120a15f5e1967b4067d3c068b9bc564f3fb432 
 
 Diff: https://reviews.apache.org/r/28771/diff/
 
 
 Testing
 ---
 
 ```
 ./pants build src/test/python/apache/aurora/client:all -vxs
 ./src/test/sh/org/apache/aurora/e2e/test_end_to_end_v2.sh
 ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
 ```
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28617: Implemented offer filtering for tasks with static vetoes.

2014-12-05 Thread Maxim Khutornenko

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

(Updated Dec. 5, 2014, 10:57 p.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

Improving banned offer lookup performance.


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


Repository: aurora


Description (updated)
---

Modified the task offer/task matching logic to skip offer matching for tasks 
previously vetoed statically.

Preliminary testing in vagrant (see pictures below) shows close to 50% 
improvement in task scheduling performance.

Update:
Testing with JMH (https://reviews.apache.org/r/28710/ and 
https://reviews.apache.org/r/28731/) shows over 97% better perf:

```
Master with cluster fillup 0.9:
Benchmark   
 Mode  SamplesScoreError  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  8291046.074 ± 145251.995  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  7522269.050 ± 142446.265  ns/op

This RB with cluster fillup 0.9:
Benchmark   
 Mode  Samples   Score  Error  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  204171.046 ± 3800.124  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  215854.129 ± 8959.851  ns/op
```


Diffs (updated)
-

  src/main/java/org/apache/aurora/scheduler/TaskVars.java 
f017cdd26ca40138a7e141f21613ed567314c399 
  src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
f66383830140e5eaba436f35ebb5192eee65947a 
  src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
ead9d28100673440168a32d114ecaa15874978a6 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
c2a342ce07bfb223193886038761f0da5230135d 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
1cb56f19c331508a1585077e9c4a98f52aac343b 
  src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java 
e1c29747c9854cf75bf63f6f085cf40ca68989af 
  src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
4e7efb3c1214c3d193afd61f162713490eb8effb 
  src/test/java/org/apache/aurora/scheduler/async/OfferQueueImplTest.java 
4cf602ad32b972c18eb5a81e9b2f59c67859bdb2 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
5647349854a5e04de749c4d809684a0066d4da06 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
6cc13231560996b144101eba36577f49017aba06 
  
src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java 
265c38d20136210e7639ac8ea915d307a4b72949 
  src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java 
411a55a8d85f60bb2703468f2d69b64b2736eee4 

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


Testing
---

./gradlew -Pq build

Tested in vagrant


File Attachments


NoStaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/7945c60b-4135-4016-a9bf-8d4815a4a573__NoStaticVetoFiltering.png
StaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/2f73b94a-5ba9-43b6-922e-e9e4ec18d0bb__StaticVetoFiltering.png


Thanks,

Maxim Khutornenko



Re: Review Request 28731: Implemented TaskScheduler benchmarks.

2014-12-05 Thread Maxim Khutornenko
  93: 5985075.676 ns/op
Iteration  94: 4735798.283 ns/op
Iteration  95: 4893389.381 ns/op
Iteration  96: 6055005.495 ns/op
Iteration  97: 4684194.915 ns/op
Iteration  98: 4649130.252 ns/op
Iteration  99: 4619602.510 ns/op
Iteration 100: 4593595.833 ns/op


Result: 5011738.309 ±(99.9%) 160249.620 ns/op [Average]
  Statistics: (min, avg, max) = (4527586.066, 5011738.309, 7052592.357), stdev 
= 472499.654
  Confidence interval (99.9%): [4851488.689, 5171987.930]


# Run complete. Total time: 00:04:29

Benchmark   
 Mode  SamplesScoreError  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  5165386.898 ± 344576.928  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  5011738.309 ± 160249.620  ns/op
```


Thanks,

Maxim Khutornenko



Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-05 Thread Maxim Khutornenko

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

(Updated Dec. 6, 2014, 12:33 a.m.)


Review request for Aurora, Kevin Sweeney and Bill Farner.


Changes
---

CR comments.


Repository: aurora


Description
---

This RB is superseding the https://reviews.apache.org/r/28474/.


I have spent some time researching the available microbenchmark frameworks and 
JMH [1] came as a clear winner:
- Active development trail [2]
- Advanced featureset and built-in optimizations improving accuracy and 
consistency [3]
- Well documented set of examples [4]
- Large community experience and collective wisdom. 


This RB adds gradle support for running JMH benchmarks and is relying on JMH 
gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.

[1] - http://openjdk.java.net/projects/code-tools/jmh/
[2] - http://hg.openjdk.java.net/code-tools/jmh/ 
[3] - 
https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
[4] - 
http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
[5] - https://github.com/melix/jmh-gradle-plugin


Diffs (updated)
-

  build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
  config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
  src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java PRE-CREATION 

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


Testing
---

$ ./gradlew jmh

Sample results generated:

```
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
# VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 1 s each
# Measurement: 3 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example

# Run progress: 0.00% complete, ETA 00:00:04
# Fork: 1 of 1
# Warmup Iteration   1: 3156839103.911 ops/s
Iteration   1: 544897.411 ops/s
Iteration   2: 3357230627.218 ops/s
Iteration   3: 3461073727.560 ops/s


Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
  Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
3461073727.560), stdev = 67833135.714
  Confidence interval (99.9%): [2146420835.212, 4621478666.247]


# Run complete. Total time: 00:00:05

Benchmark  Mode  Samples   Score
Error  Units
o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
1237528915.517  ops/s

```


Thanks,

Maxim Khutornenko



Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-05 Thread Maxim Khutornenko


 On Dec. 5, 2014, 7:42 p.m., Kevin Sweeney wrote:
  build.gradle, line 53
  https://reviews.apache.org/r/28710/diff/1/?file=782698#file782698line53
 
  This should be unneeded.

Dropped.


 On Dec. 5, 2014, 7:42 p.m., Kevin Sweeney wrote:
  build.gradle, line 103
  https://reviews.apache.org/r/28710/diff/3/?file=783833#file783833line103
 
  im not convinced you want to apply this to the api subproject.

This was only needed to make :api recognize .jmh configuration. However, played 
a bit more and found a way to reference parent configuration. Dropped.


 On Dec. 5, 2014, 7:42 p.m., Kevin Sweeney wrote:
  build.gradle, line 156
  https://reviews.apache.org/r/28710/diff/3/?file=783833#file783833line156
 
  Do we want to apply jmh to the 'api' project? I'd think we'd want to 
  add the root. That will give you the benefit of not having to disable this 
  task on the api project at all.

Gone.


 On Dec. 5, 2014, 7:42 p.m., Kevin Sweeney wrote:
  build.gradle, line 165
  https://reviews.apache.org/r/28710/diff/3/?file=783833#file783833line165
 
  should this be a test scope? also should this be in the root project 
  instead of the api project?

It's only needed to resolve /jmh deps. Test scope is irrelevant here.


 On Dec. 5, 2014, 7:42 p.m., Kevin Sweeney wrote:
  build.gradle, line 458
  https://reviews.apache.org/r/28710/diff/3/?file=783833#file783833line458
 
  Does
  
  ```groovy
  tasks('jmh')  {
//...
  }
  ```
  
  work?

It does not: ` Could not find method tasks() for arguments [jmh] on root 
project 'aurora'.`


- Maxim


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


On Dec. 5, 2014, 6:32 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28710/
 ---
 
 (Updated Dec. 5, 2014, 6:32 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This RB is superseding the https://reviews.apache.org/r/28474/.
 
 
 I have spent some time researching the available microbenchmark frameworks 
 and JMH [1] came as a clear winner:
 - Active development trail [2]
 - Advanced featureset and built-in optimizations improving accuracy and 
 consistency [3]
 - Well documented set of examples [4]
 - Large community experience and collective wisdom. 
 
 
 This RB adds gradle support for running JMH benchmarks and is relying on JMH 
 gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.
 
 [1] - http://openjdk.java.net/projects/code-tools/jmh/
 [2] - http://hg.openjdk.java.net/code-tools/jmh/ 
 [3] - 
 https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
 [4] - 
 http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
 [5] - https://github.com/melix/jmh-gradle-plugin
 
 
 Diffs
 -
 
   build.gradle 152ba631e2dd07f0306e58e355274e10a4128140 
   config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
   src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28710/diff/
 
 
 Testing
 ---
 
 $ ./gradlew jmh
 
 Sample results generated:
 
 ```
 # VM invoker: 
 /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
 # VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
 -Duser.variant
 # Warmup: 1 iterations, 1 s each
 # Measurement: 3 iterations, 1 s each
 # Timeout: 10 min per iteration
 # Threads: 1 thread, will synchronize iterations
 # Benchmark mode: Throughput, ops/time
 # Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example
 
 # Run progress: 0.00% complete, ETA 00:00:04
 # Fork: 1 of 1
 # Warmup Iteration   1: 3156839103.911 ops/s
 Iteration   1: 544897.411 ops/s
 Iteration   2: 3357230627.218 ops/s
 Iteration   3: 3461073727.560 ops/s
 
 
 Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
   Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
 3461073727.560), stdev = 67833135.714
   Confidence interval (99.9%): [2146420835.212, 4621478666.247]
 
 
 # Run complete. Total time: 00:00:05
 
 Benchmark  Mode  Samples   Score  
   Error  Units
 o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
 1237528915.517  ops/s
 
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28660: Reduce minimum branch coverage requirement to avoid flakiness.

2014-12-04 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 3, 2014, 7:02 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28660/
 ---
 
 (Updated Dec. 3, 2014, 7:02 p.m.)
 
 
 Review request for Aurora and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Reduce minimum branch coverage requirement to avoid flakiness.
 
 
 Diffs
 -
 
   build.gradle fb729c5096108c535229e266fa9649f997e6da37 
 
 Diff: https://reviews.apache.org/r/28660/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28674: Remove Response.messageDEPRECATED field.

2014-12-04 Thread Maxim Khutornenko

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



src/main/python/apache/aurora/client/base.py
https://reviews.apache.org/r/28674/#comment106024

This uses a different quoting style than the rest of the file.



src/main/python/apache/aurora/client/base.py
https://reviews.apache.org/r/28674/#comment106025

This will str() on a ResponseDetail object including the struct details 
that we don't need: 

```
$ ./pants py src/main/python/apache/aurora/client:base
 from gen.apache.aurora.api.ttypes import Response, ResponseDetail, 
ResponseCode
 resp = Response(responseCode=ResponseCode.OK, 
details=[ResponseDetail(message='Quota check successful.')])
 ', '.join(map(str, resp.details or []))
ResponseDetail(message='Quota check successful.')
```



src/test/python/apache/aurora/client/api/test_job_monitor.py
https://reviews.apache.org/r/28674/#comment106028

Use kvarg 'message=' for consistency?



src/test/python/apache/aurora/client/api/test_quota_check.py
https://reviews.apache.org/r/28674/#comment106029

same here



src/test/python/apache/aurora/client/api/test_task_util.py
https://reviews.apache.org/r/28674/#comment106032

same here


- Maxim Khutornenko


On Dec. 3, 2014, 8:34 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28674/
 ---
 
 (Updated Dec. 3, 2014, 8:34 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-466
 https://issues.apache.org/jira/browse/AURORA-466
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Remove Response.message field.
 
 
 Diffs
 -
 
   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
 6b63f04a7113527e26d7f38e877b0ebd07822108 
   src/main/java/org/apache/aurora/scheduler/thrift/Util.java 
 d879db4157c7a2c782e3213974067d86b6184f04 
   src/main/python/apache/aurora/client/api/BUILD 
 8b0da6725362c6d9a3af6524a76a855a9bcbfd40 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/api/command_runner.py 
 14a316b6cda671764f2b2ac1ba5bbfef15eb1ab5 
   src/main/python/apache/aurora/client/api/quota_check.py 
 5877cba5dd06b2caa75ed0cab9786a80c2ae71b6 
   src/main/python/apache/aurora/client/api/restarter.py 
 43599e7ef7d17441f89f4a3a08b39b86d7d6fb5b 
   src/main/python/apache/aurora/client/api/updater.py 
 2092ff31141b6ccfedf0af673fe8dc2a74a7828e 
   src/main/python/apache/aurora/client/base.py 
 2c7d8160b23dbca0979cecf3bb44b904bf0d8de6 
   src/main/python/apache/aurora/client/cli/context.py 
 96c386e83db7b7c16419ca05b9155dd527bfb834 
   src/main/python/apache/aurora/client/cli/task.py 
 8a139db02ba6baf0dc558ccdba76d194fb0ebe88 
   src/main/python/apache/aurora/client/commands/admin.py 
 cb5ae88e3f39b7d7fbb80593be664809fbaa8958 
   src/main/python/apache/aurora/client/commands/core.py 
 ee227165d6f6b7c2a5c51d9e70b25b8cd0179381 
   src/main/python/apache/aurora/client/hooks/hooked_api.py 
 91efe5248144049d6a13b1ec81ffe08522df1ee9 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  d687f572b467a76e79d55ea1d7eb0abf7ec61bbd 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/api/test_disambiguator.py 
 e9523ac67a67f83f55a7d79f38a5c13a9a90694c 
   src/test/python/apache/aurora/client/api/test_instance_watcher.py 
 abbbdbe953e3a81b64eb77ab096cef22c6ffc4c6 
   src/test/python/apache/aurora/client/api/test_job_monitor.py 
 27d8025bc80cff22c2f025302d1fe0519d8632e9 
   src/test/python/apache/aurora/client/api/test_quota_check.py 
 cb443c227589d69559c92444232eb6ba7d9259eb 
   src/test/python/apache/aurora/client/api/test_restarter.py 
 eb0af3bc588c088aa2aca8eb561cbd90d28209e1 
   src/test/python/apache/aurora/client/api/test_sla.py 
 50a6c47f00c77265328d6eacc835884e158b9e20 
   src/test/python/apache/aurora/client/api/test_task_util.py 
 3e772b949b0ec8b9cece62fc1ed46059a8310195 
   src/test/python/apache/aurora/client/api/test_updater.py 
 a32fc529cb1b23ab926a9180debb68bb826f66a8 
   src/test/python/apache/aurora/client/cli/util.py 
 0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 
   src/test/python/apache/aurora/client/commands/test_admin.py 
 f9261affcc7d2f5391712fa0d0eb84e89a13bd70 
   src/test/python/apache/aurora/client/commands/test_kill.py 
 4ac742f4c7f3528cee0cdc25b9624ffde8384b11 
   src/test/python/apache/aurora/client/commands/util.py 
 c06de50e81be57cbf0480b1566f0efcec07f8a9d 
   src/test/python/apache/aurora/client/test_base.py 
 785784b3cb8e670111bb367363acc45772a8ea3e 
 
 Diff: https://reviews.apache.org/r

Re: Review Request 28693: Make abstract method annotations on ConfigurationPlugin effective.

2014-12-04 Thread Maxim Khutornenko

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



src/main/python/apache/aurora/client/cli/__init__.py
https://reviews.apache.org/r/28693/#comment106171

Why not keeping @abstractmethod attributes and dropping the return 
statements instead? With your modification there is no need to keep this noop 
behavior as tests like EmptyPlugin below would not be possible anyway.


- Maxim Khutornenko


On Dec. 4, 2014, 6:36 a.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28693/
 ---
 
 (Updated Dec. 4, 2014, 6:36 a.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This makes ConfigurationPlugin inherit from AbstractClass so the 
 @abstractmethod annotation is useful. This also removes the annotation for 
 the two methods with default values.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
 
 Diff: https://reviews.apache.org/r/28693/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client::
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 28693: Make abstract method annotations on ConfigurationPlugin effective.

2014-12-04 Thread Maxim Khutornenko


 On Dec. 4, 2014, 5:21 p.m., Maxim Khutornenko wrote:
  src/main/python/apache/aurora/client/cli/__init__.py, lines 172-175
  https://reviews.apache.org/r/28693/diff/1/?file=782496#file782496line172
 
  Why not keeping @abstractmethod attributes and dropping the return 
  statements instead? With your modification there is no need to keep this 
  noop behavior as tests like EmptyPlugin below would not be possible 
  anyway.
 
 Zameer Manji wrote:
 The return statements provide default behaviour that plugins should have 
 to prevent AURORA-362. If get_options does not return an iterable the 
 argument handling code will crash and before_dispatch needs to return 
 raw_args to prevent the clobbering of user passed in commandline arguments.
 
 This reduces the work that plugins need to do if they are just interested 
 in implementing before_execution or after_execution.

I don't see how `before_dispatch` is semantically different from 
`before_execution` for the plugin implementor. The only difference is that one 
is expected to return `raw_args` and the other one is void. These noops provide 
no additional value besides questionable convenience on override. I would say 
drop the return statements, convert these methods back to abstract and properly 
document return type expectations. This way there is no second guessing what 
needs to be overriden and what isn't.


- Maxim


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


On Dec. 4, 2014, 6:36 a.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28693/
 ---
 
 (Updated Dec. 4, 2014, 6:36 a.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This makes ConfigurationPlugin inherit from AbstractClass so the 
 @abstractmethod annotation is useful. This also removes the annotation for 
 the two methods with default values.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
 
 Diff: https://reviews.apache.org/r/28693/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client::
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 28692: Simplify logging in the Aurora client.

2014-12-04 Thread Maxim Khutornenko

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


Can you paste a few examples from vagrant (preferrably job update) before and 
after your change? That would help reviewing.


src/main/python/apache/aurora/client/cli/context.py
https://reviews.apache.org/r/28692/#comment106184

Why is this jumping from TRANSCRIPT to INFO? Will every invocation now log 
the entire config?



src/main/python/apache/aurora/client/cli/context.py
https://reviews.apache.org/r/28692/#comment106185

same question here


- Maxim Khutornenko


On Dec. 4, 2014, 6:27 a.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28692/
 ---
 
 (Updated Dec. 4, 2014, 6:27 a.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-919
 https://issues.apache.org/jira/browse/AURORA-919
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This patch removes a custom log level and adds a --verbose flag to the output.
 
 
 Diffs
 -
 
   src/main/python/apache/aurora/client/cli/BUILD 
 ebe681a0d1735b7cc695dc3b7a14c4292d87ae32 
   src/main/python/apache/aurora/client/cli/__init__.py 
 6e553d8af459e575b2d62282a3bc0d1e266203d8 
   src/main/python/apache/aurora/client/cli/context.py 
 51c7d24dca664e476e62f1864d095416dfab70e4 
   src/main/python/apache/aurora/client/cli/logsetup.py 
 55d99c42f643910db0bf3c24022596383e160276 
   src/main/python/apache/aurora/client/cli/standalone_client.py 
 b7c8de66d6e4664b536911f826e36a984e8d0fef 
   src/test/python/apache/aurora/client/cli/test_plugins.py 
 7a0a31818cbc57de952d7817f8e7c8fa1e84b25a 
 
 Diff: https://reviews.apache.org/r/28692/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python/apache/aurora/client::
 
 
 Thanks,
 
 Zameer Manji
 




Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-04 Thread Maxim Khutornenko

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

Review request for Aurora, Kevin Sweeney and Bill Farner.


Repository: aurora


Description
---

This RB is superseding the https://reviews.apache.org/r/28474/.


I have spent some time researching the available microbenchmark frameworks and 
JMH [1] came as a clear winner:
- Active development trail [2]
- Advanced featureset and built-in optimizations improving accuracy and 
consistency [3]
- Well documented set of examples [4]
- Large community experience and collective wisdom. 


This RB adds gradle support for running JMH benchmarks and is relying on JMH 
gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.

[1] - http://openjdk.java.net/projects/code-tools/jmh/
[2] - http://hg.openjdk.java.net/code-tools/jmh/ 
[3] - 
https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
[4] - 
http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
[5] - https://github.com/melix/jmh-gradle-plugin


Diffs
-

  build.gradle fb729c5096108c535229e266fa9649f997e6da37 
  config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
  src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java PRE-CREATION 

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


Testing
---

$ ./gradlew jmh

Sample results generated:

```
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
# VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 1 s each
# Measurement: 3 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example

# Run progress: 0.00% complete, ETA 00:00:04
# Fork: 1 of 1
# Warmup Iteration   1: 3156839103.911 ops/s
Iteration   1: 544897.411 ops/s
Iteration   2: 3357230627.218 ops/s
Iteration   3: 3461073727.560 ops/s


Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
  Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
3461073727.560), stdev = 67833135.714
  Confidence interval (99.9%): [2146420835.212, 4621478666.247]


# Run complete. Total time: 00:00:05

Benchmark  Mode  Samples   Score
Error  Units
o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
1237528915.517  ops/s

```


Thanks,

Maxim Khutornenko



Re: Review Request 28474: Added manual perf tests for the scheduling pipeline.

2014-12-04 Thread Maxim Khutornenko

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


Discarding this in favor of benchmark harness started in 
https://reviews.apache.org/r/28710/.

- Maxim Khutornenko


On Nov. 26, 2014, 6:15 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28474/
 ---
 
 (Updated Nov. 26, 2014, 6:15 p.m.)
 
 
 Review request for Aurora and Bill Farner.
 
 
 Bugs: AURORA-909
 https://issues.apache.org/jira/browse/AURORA-909
 
 
 Repository: aurora
 
 
 Description
 ---
 
 A manual testbed for the upcoming AURORA-909 work.
 
 
 Diffs
 -
 
   src/test/java/org/apache/aurora/scheduler/async/Offers.java 
 8293dd181b0d062e89776fdc1205c1c227d6bb6c 
   src/test/java/org/apache/aurora/scheduler/async/SchedulerPerfIT.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28474/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 IDE manual run:
 
 Nov 26, 2014 10:12:21 AM 
 org.apache.aurora.scheduler.async.preemptor.PreemptorModule configure
 INFO: Preemptor Enabled.
 Nov 26, 2014 10:12:21 AM com.twitter.common.util.BuildInfo fetchProperties
 INFO: Fetching build properties from build.properties
 Nov 26, 2014 10:12:21 AM com.twitter.common.util.BuildInfo fetchProperties
 WARNING: Failed to fetch build properties from build.properties
 Nov 26, 2014 10:12:21 AM 
 com.twitter.common.application.modules.StatsModule$StartStatPoller execute
 INFO: Build information: {}
 Nov 26, 2014 10:12:26 AM org.apache.aurora.scheduler.async.SchedulerPerfIT 
 runTest
 INFO: Results for: INSUFFICIENT_RESOURCES
 Nov 26, 2014 10:12:26 AM org.apache.aurora.scheduler.async.SchedulerPerfIT 
 logDuration
 INFO: Mean task_schedule_attempt duration: 737660.0796871068 ns
 Nov 26, 2014 10:12:26 AM org.apache.aurora.scheduler.async.SchedulerPerfIT 
 logDuration
 INFO: Mean offer_queue_launch_first duration: 332330.25185686833 ns
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28710: Adding JMH framework support for scheduler performance analysis.

2014-12-04 Thread Maxim Khutornenko


 On Dec. 4, 2014, 8:12 p.m., Kevin Sweeney wrote:
  build.gradle, line 23
  https://reviews.apache.org/r/28710/diff/1/?file=782698#file782698line23
 
  Looks like you want the new-style block here instead:
  
  https://plugins.gradle.org/plugin/me.champeau.gradle.jmh

Great suggestion. Done.


- Maxim


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


On Dec. 4, 2014, 7:36 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28710/
 ---
 
 (Updated Dec. 4, 2014, 7:36 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Bill Farner.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This RB is superseding the https://reviews.apache.org/r/28474/.
 
 
 I have spent some time researching the available microbenchmark frameworks 
 and JMH [1] came as a clear winner:
 - Active development trail [2]
 - Advanced featureset and built-in optimizations improving accuracy and 
 consistency [3]
 - Well documented set of examples [4]
 - Large community experience and collective wisdom. 
 
 
 This RB adds gradle support for running JMH benchmarks and is relying on JMH 
 gradle plugin [5]. The benchmarks are run via `./gradlew jmh` command.
 
 [1] - http://openjdk.java.net/projects/code-tools/jmh/
 [2] - http://hg.openjdk.java.net/code-tools/jmh/ 
 [3] - 
 https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
 [4] - 
 http://hg.openjdk.java.net/code-tools/jmh/file/adb6047266d8/jmh-samples/src/main/java/org/openjdk/jmh/samples
 [5] - https://github.com/melix/jmh-gradle-plugin
 
 
 Diffs
 -
 
   build.gradle fb729c5096108c535229e266fa9649f997e6da37 
   config/findbugs/excludeFilter.xml d6c1b1681c2d8505a088f9fb082ce11ac400126f 
   src/jmh/java/org/apache/aurora/benchmark/SchedulerBenchmark.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28710/diff/
 
 
 Testing
 ---
 
 $ ./gradlew jmh
 
 Sample results generated:
 
 ```
 # VM invoker: 
 /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java
 # VM options: -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
 -Duser.variant
 # Warmup: 1 iterations, 1 s each
 # Measurement: 3 iterations, 1 s each
 # Timeout: 10 min per iteration
 # Threads: 1 thread, will synchronize iterations
 # Benchmark mode: Throughput, ops/time
 # Benchmark: org.apache.aurora.benchmark.SchedulerBenchmark.example
 
 # Run progress: 0.00% complete, ETA 00:00:04
 # Fork: 1 of 1
 # Warmup Iteration   1: 3156839103.911 ops/s
 Iteration   1: 544897.411 ops/s
 Iteration   2: 3357230627.218 ops/s
 Iteration   3: 3461073727.560 ops/s
 
 
 Result: 3383949750.729 ±(99.9%) 1237528915.517 ops/s [Average]
   Statistics: (min, avg, max) = (544897.411, 3383949750.729, 
 3461073727.560), stdev = 67833135.714
   Confidence interval (99.9%): [2146420835.212, 4621478666.247]
 
 
 # Run complete. Total time: 00:00:05
 
 Benchmark  Mode  Samples   Score  
   Error  Units
 o.a.a.b.SchedulerBenchmark.examplethrpt3  3383949750.729 ± 
 1237528915.517  ops/s
 
 ```
 
 
 Thanks,
 
 Maxim Khutornenko
 




Review Request 28731: Implemented TaskScheduler benchmarks.

2014-12-04 Thread Maxim Khutornenko
  97: 4684194.915 ns/op
Iteration  98: 4649130.252 ns/op
Iteration  99: 4619602.510 ns/op
Iteration 100: 4593595.833 ns/op


Result: 5011738.309 ±(99.9%) 160249.620 ns/op [Average]
  Statistics: (min, avg, max) = (4527586.066, 5011738.309, 7052592.357), stdev 
= 472499.654
  Confidence interval (99.9%): [4851488.689, 5171987.930]


# Run complete. Total time: 00:04:29

Benchmark   
 Mode  SamplesScoreError  Units
o.a.a.b.SchedulingBenchmarks.ConstraintMismatchsSchedulingBenchmark.example 
 avgt  100  5165386.898 ± 344576.928  ns/op
o.a.a.b.SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.example   
 avgt  100  5011738.309 ± 160249.620  ns/op
```


Thanks,

Maxim Khutornenko



Re: Review Request 28674: Remove Response.messageDEPRECATED field.

2014-12-04 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 5, 2014, 1:09 a.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28674/
 ---
 
 (Updated Dec. 5, 2014, 1:09 a.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-466
 https://issues.apache.org/jira/browse/AURORA-466
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Remove Response.message field.
 
 
 Diffs
 -
 
   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
 7d55dce06c77b17b2f895834e88e5c8543462b31 
   src/main/java/org/apache/aurora/scheduler/thrift/Util.java 
 d879db4157c7a2c782e3213974067d86b6184f04 
   src/main/python/apache/aurora/client/api/BUILD 
 8b0da6725362c6d9a3af6524a76a855a9bcbfd40 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/api/command_runner.py 
 14a316b6cda671764f2b2ac1ba5bbfef15eb1ab5 
   src/main/python/apache/aurora/client/api/quota_check.py 
 5877cba5dd06b2caa75ed0cab9786a80c2ae71b6 
   src/main/python/apache/aurora/client/api/restarter.py 
 43599e7ef7d17441f89f4a3a08b39b86d7d6fb5b 
   src/main/python/apache/aurora/client/api/updater.py 
 2092ff31141b6ccfedf0af673fe8dc2a74a7828e 
   src/main/python/apache/aurora/client/base.py 
 2c7d8160b23dbca0979cecf3bb44b904bf0d8de6 
   src/main/python/apache/aurora/client/cli/context.py 
 96c386e83db7b7c16419ca05b9155dd527bfb834 
   src/main/python/apache/aurora/client/cli/task.py 
 8a139db02ba6baf0dc558ccdba76d194fb0ebe88 
   src/main/python/apache/aurora/client/commands/admin.py 
 cb5ae88e3f39b7d7fbb80593be664809fbaa8958 
   src/main/python/apache/aurora/client/commands/core.py 
 ee227165d6f6b7c2a5c51d9e70b25b8cd0179381 
   src/main/python/apache/aurora/client/hooks/hooked_api.py 
 91efe5248144049d6a13b1ec81ffe08522df1ee9 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  072ea2b916d9d7d01cd7ba75c79b96896dccca7f 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/api/test_disambiguator.py 
 e9523ac67a67f83f55a7d79f38a5c13a9a90694c 
   src/test/python/apache/aurora/client/api/test_instance_watcher.py 
 abbbdbe953e3a81b64eb77ab096cef22c6ffc4c6 
   src/test/python/apache/aurora/client/api/test_job_monitor.py 
 27d8025bc80cff22c2f025302d1fe0519d8632e9 
   src/test/python/apache/aurora/client/api/test_quota_check.py 
 cb443c227589d69559c92444232eb6ba7d9259eb 
   src/test/python/apache/aurora/client/api/test_restarter.py 
 eb0af3bc588c088aa2aca8eb561cbd90d28209e1 
   src/test/python/apache/aurora/client/api/test_sla.py 
 50a6c47f00c77265328d6eacc835884e158b9e20 
   src/test/python/apache/aurora/client/api/test_task_util.py 
 3e772b949b0ec8b9cece62fc1ed46059a8310195 
   src/test/python/apache/aurora/client/api/test_updater.py 
 a32fc529cb1b23ab926a9180debb68bb826f66a8 
   src/test/python/apache/aurora/client/cli/util.py 
 0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 
   src/test/python/apache/aurora/client/commands/test_admin.py 
 f9261affcc7d2f5391712fa0d0eb84e89a13bd70 
   src/test/python/apache/aurora/client/commands/test_kill.py 
 4ac742f4c7f3528cee0cdc25b9624ffde8384b11 
   src/test/python/apache/aurora/client/commands/util.py 
 c06de50e81be57cbf0480b1566f0efcec07f8a9d 
   src/test/python/apache/aurora/client/test_base.py 
 785784b3cb8e670111bb367363acc45772a8ea3e 
 
 Diff: https://reviews.apache.org/r/28674/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28607: Add a caching ClusterState implementation.

2014-12-02 Thread Maxim Khutornenko

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



src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
https://reviews.apache.org/r/28607/#comment105873

minor nit: you might want to have it outside the synchronized block to 
further reduce lock scope.



src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
https://reviews.apache.org/r/28607/#comment105877

Would it make sense to do it conditionally, i.e.:
```java
if (!Tasks.SLAVE_ASSIGNED_STATES.contains(stateChange.getNewState()) {
  Iterables.remove...
} else {
  victims.put...
}
```


- Maxim Khutornenko


On Dec. 2, 2014, 10:03 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28607/
 ---
 
 (Updated Dec. 2, 2014, 10:03 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Add a caching ClusterState implementation.
 
 
 Diffs
 -
 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
  PRE-CREATION 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 3524dc595e7b61a531912843f90b01a87bc57cc4 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModule.java
  489c0bfa22aae14fbd3fd2ee9e5bd32b7c3aafa5 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterStateTest.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28607/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Review Request 28617: Implemented offer filtering for tasks with static vetoes.

2014-12-02 Thread Maxim Khutornenko

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

Review request for Aurora, Kevin Sweeney and Bill Farner.


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


Repository: aurora


Description
---

Modified the task offer/task matching logic to skip offer matching for tasks 
previously vetoed statically.

I will follow up with more accurate measurements 
(https://reviews.apache.org/r/28474/) but preliminary testing in vagrant (see 
pictures below) shows close to 50% improvement in task scheduling performance.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/TaskVars.java 
f017cdd26ca40138a7e141f21613ed567314c399 
  src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
f66383830140e5eaba436f35ebb5192eee65947a 
  src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
ead9d28100673440168a32d114ecaa15874978a6 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
c2a342ce07bfb223193886038761f0da5230135d 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
1cb56f19c331508a1585077e9c4a98f52aac343b 
  src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java 
e1c29747c9854cf75bf63f6f085cf40ca68989af 
  src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
4e7efb3c1214c3d193afd61f162713490eb8effb 
  src/test/java/org/apache/aurora/scheduler/async/OfferQueueImplTest.java 
4cf602ad32b972c18eb5a81e9b2f59c67859bdb2 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
5647349854a5e04de749c4d809684a0066d4da06 
  src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
6cc13231560996b144101eba36577f49017aba06 
  
src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java 
265c38d20136210e7639ac8ea915d307a4b72949 
  src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java 
411a55a8d85f60bb2703468f2d69b64b2736eee4 

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


Testing
---

./gradlew -Pq build

Tested in vagrant


File Attachments


NoStaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/7945c60b-4135-4016-a9bf-8d4815a4a573__NoStaticVetoFiltering.png
StaticVetoFiltering.png
  
https://reviews.apache.org/media/uploaded/files/2014/12/03/2f73b94a-5ba9-43b6-922e-e9e4ec18d0bb__StaticVetoFiltering.png


Thanks,

Maxim Khutornenko



Re: Review Request 28607: Add a caching ClusterState implementation.

2014-12-02 Thread Maxim Khutornenko


 On Dec. 2, 2014, 11:09 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java,
   line 58
  https://reviews.apache.org/r/28607/diff/1/?file=780416#file780416line58
 
  Would it make sense to do it conditionally, i.e.:
  ```java
  if (!Tasks.SLAVE_ASSIGNED_STATES.contains(stateChange.getNewState()) {
Iterables.remove...
  } else {
victims.put...
  }
  ```
 
 Bill Farner wrote:
 That would introduce duplicates, e.g. PENDING - ASSIGNED - RUNNING 
 would result in 2 entries for the task.

Why not use a HashMultimap to store victims then? I don't see anything in the 
PreemptionVictim that would be different between task state transitions.


- Maxim


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


On Dec. 2, 2014, 10:03 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28607/
 ---
 
 (Updated Dec. 2, 2014, 10:03 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Add a caching ClusterState implementation.
 
 
 Diffs
 -
 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
  PRE-CREATION 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 3524dc595e7b61a531912843f90b01a87bc57cc4 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModule.java
  489c0bfa22aae14fbd3fd2ee9e5bd32b7c3aafa5 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterStateTest.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28607/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28607: Add a caching ClusterState implementation.

2014-12-02 Thread Maxim Khutornenko

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

Ship it!



src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
https://reviews.apache.org/r/28607/#comment105910

This can be further simplified (unless you are concerned about the heap 
churn):
```java
victims.remove(slaveId, 
PreemptionVictim.fromTask(stateChange.getTask().getAssignedTask());
```


- Maxim Khutornenko


On Dec. 3, 2014, 1:39 a.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28607/
 ---
 
 (Updated Dec. 3, 2014, 1:39 a.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Add a caching ClusterState implementation.
 
 
 Diffs
 -
 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterState.java
  PRE-CREATION 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 3524dc595e7b61a531912843f90b01a87bc57cc4 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModule.java
  489c0bfa22aae14fbd3fd2ee9e5bd32b7c3aafa5 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/CachedClusterStateTest.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28607/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28623: Remove getVersion RPC and DEPRECATEDversion Response field.

2014-12-02 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 3, 2014, 2:13 a.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28623/
 ---
 
 (Updated Dec. 3, 2014, 2:13 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Kevin Sweeney.
 
 
 Bugs: AURORA-143 and AURORA-467
 https://issues.apache.org/jira/browse/AURORA-143
 https://issues.apache.org/jira/browse/AURORA-467
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Remove getVersion RPC and DEPRECATEDversion Response field.
 
 
 Diffs
 -
 
   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
 6b63f04a7113527e26d7f38e877b0ebd07822108 
   
 src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
  0898c62315c5a47628ad629182c3177c86a00bce 
   
 src/main/java/org/apache/aurora/scheduler/thrift/aop/ServerInfoInterceptor.java
  3406722067af40a91fe39340d94ee03d20d7ddbd 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  d687f572b467a76e79d55ea1d7eb0abf7ec61bbd 
   src/test/java/org/apache/aurora/scheduler/thrift/aop/ForwardingThrift.java 
 04979084b5352d3044bd3c2ba7071e10d9992765 
   
 src/test/java/org/apache/aurora/scheduler/thrift/aop/ServerInfoInterceptorTest.java
  840b3f88e7de306fa0af73593b5bac6cc00528da 
 
 Diff: https://reviews.apache.org/r/28623/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28571: Reject jobs containing an empty cron schedule.

2014-12-01 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Dec. 1, 2014, 8:07 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28571/
 ---
 
 (Updated Dec. 1, 2014, 8:07 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Bugs: AURORA-424
 https://issues.apache.org/jira/browse/AURORA-424
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Reject jobs containing an empty cron schedule.
 
 
 Diffs
 -
 
   
 src/main/java/org/apache/aurora/scheduler/configuration/SanitizedConfiguration.java
  fe3ad4ca973f5ae494250ffe50d419032be0d984 
   src/main/java/org/apache/aurora/scheduler/cron/SanitizedCronJob.java 
 0e35cfbe6519050d86c154cc4ee545400757503e 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  b28b3ae9010bd4bae652bbf1b2ceb45e01e23784 
 
 Diff: https://reviews.apache.org/r/28571/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28572: Minimize the state consumed when collecting preemption victims.

2014-12-01 Thread Maxim Khutornenko

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

Ship it!



src/main/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterState.java
https://reviews.apache.org/r/28572/#comment105758

Please, drop the now unused TASK_TO_SLAVE_ID.


- Maxim Khutornenko


On Dec. 1, 2014, 8:32 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28572/
 ---
 
 (Updated Dec. 1, 2014, 8:32 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This should be the last step before creating a caching `ClusterState` 
 implementation.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 4f0019a1a1272e27e600c47641a05d320035 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterState.java
  9d83acc4177076411c5ce6c8304fcf75cb029597 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptionVictim.java
  PRE-CREATION 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorImpl.java 
 f013383b095968b0de6e917d2311c85d6afe53f7 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterStateTest.java
  8f91ff684dddc0591e71503afc0f999e508b7dbe 
 
 Diff: https://reviews.apache.org/r/28572/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28411: Adding quota check into replaceCronTemplate rpc.

2014-11-26 Thread Maxim Khutornenko

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


@ReviewBot retry

- Maxim Khutornenko


On Nov. 24, 2014, 9:27 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28411/
 ---
 
 (Updated Nov. 24, 2014, 9:27 p.m.)
 
 
 Review request for Aurora and Bill Farner.
 
 
 Bugs: AURORA-946
 https://issues.apache.org/jira/browse/AURORA-946
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Merged scheduleCronJob and replaceCronTemplate implementations. 
 
 
 Diffs
 -
 
   
 src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
  a5e869fc52ab6c4c28e6965585b015440f448f59 
   src/main/thrift/org/apache/aurora/gen/api.thrift 
 b91fca9383891af15477a6f6ef7c407bfa125303 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  de5f21a084109e5f31a7e5fca1b8ee265e30b893 
 
 Diff: https://reviews.apache.org/r/28411/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 vagrant@vagrant-ubuntu-trusty-64:~$ aurora update  
 devcluster/vagrant/test/cron_hello_world2 
 aurora/examples/jobs/cron_hello_world.aurora 
 WARNING: update is an aurora clientv1 command which will be deprecated soon
 To run this command using clientv2, use 'aurora job update 
 devcluster/vagrant/test/cron_hello_world2 
 aurora/examples/jobs/cron_hello_world.aurora 
 --health-check-interval-seconds=3'
  INFO] Updating job: cron_hello_world2
  INFO] Response from scheduler: ERROR (message: Aborting update without 
 rollback! Fatal error: Response from scheduler: INVALID_REQUEST (message: 
 Insufficient resource quota: CPU quota exceeded by 1.00 core(s); RAM quota 
 exceeded by 1024.00 MB; DISK quota exceeded by 1024.00 MB))
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28411: Adding quota check into replaceCronTemplate rpc.

2014-11-26 Thread Maxim Khutornenko

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

(Updated Nov. 27, 2014, 12:36 a.m.)


Review request for Aurora and Bill Farner.


Changes
---

Rebased.


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


Repository: aurora


Description
---

Merged scheduleCronJob and replaceCronTemplate implementations. 


Diffs (updated)
-

  api/src/main/thrift/org/apache/aurora/gen/api.thrift 
b91fca9383891af15477a6f6ef7c407bfa125303 
  
src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java 
9087eb2a5b305ceb1c5d50c75b9ca2ea2143a10f 
  
src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
 c602b304fc7d8abbcf397f30dd364d6aa1b4de9b 

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


Testing
---

./gradlew -Pq build

vagrant@vagrant-ubuntu-trusty-64:~$ aurora update  
devcluster/vagrant/test/cron_hello_world2 
aurora/examples/jobs/cron_hello_world.aurora 
WARNING: update is an aurora clientv1 command which will be deprecated soon
To run this command using clientv2, use 'aurora job update 
devcluster/vagrant/test/cron_hello_world2 
aurora/examples/jobs/cron_hello_world.aurora --health-check-interval-seconds=3'
 INFO] Updating job: cron_hello_world2
 INFO] Response from scheduler: ERROR (message: Aborting update without 
rollback! Fatal error: Response from scheduler: INVALID_REQUEST (message: 
Insufficient resource quota: CPU quota exceeded by 1.00 core(s); RAM quota 
exceeded by 1024.00 MB; DISK quota exceeded by 1024.00 MB))


Thanks,

Maxim Khutornenko



Re: Review Request 28398: Adding cron check into aurora beta-update start.

2014-11-25 Thread Maxim Khutornenko

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

(Updated Nov. 25, 2014, 6 p.m.)


Review request for Aurora, David McLaughlin, Kevin Sweeney, and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Failing fast aurora beta-update start when a cron schedule is specified.

Also, updated cron command help messages and docs.


Diffs (updated)
-

  docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
  docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
  
src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java 
a5e869fc52ab6c4c28e6965585b015440f448f59 
  src/main/python/apache/aurora/client/cli/cron.py 
cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
  src/main/python/apache/aurora/client/cli/update.py 
12774af8bcd1c953fdbc799b0a142c27407d69f5 
  
src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
 de5f21a084109e5f31a7e5fca1b8ee265e30b893 
  src/test/python/apache/aurora/client/cli/test_supdate.py 
7637352feea6b07408256158814c05bc17ec14f3 

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


Testing
---

./pants src/test/python:all

Tested in vagrant.


Thanks,

Maxim Khutornenko



Re: Review Request 28398: Adding cron check into aurora beta-update start.

2014-11-25 Thread Maxim Khutornenko


 On Nov. 24, 2014, 7:48 p.m., David McLaughlin wrote:
  src/main/python/apache/aurora/client/cli/cron.py, line 79
  https://reviews.apache.org/r/28398/diff/1/?file=774538#file774538line79
 
  s/existing //

Done.


- Maxim


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


On Nov. 24, 2014, 7:19 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28398/
 ---
 
 (Updated Nov. 24, 2014, 7:19 p.m.)
 
 
 Review request for Aurora, David McLaughlin, Kevin Sweeney, and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Failing fast aurora beta-update start when a cron schedule is specified.
 
 Also, updated cron command help messages and docs.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   
 src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
  a5e869fc52ab6c4c28e6965585b015440f448f59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  de5f21a084109e5f31a7e5fca1b8ee265e30b893 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
 
 Diff: https://reviews.apache.org/r/28398/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 Tested in vagrant.
 
 
 Thanks,
 
 Maxim Khutornenko
 




Review Request 28445: Improving messages in CronJobManager.

2014-11-25 Thread Maxim Khutornenko

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

Review request for Aurora and Kevin Sweeney.


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


Repository: aurora


Description
---

Fixed checkCronExists() error message.

Also, refactored message handling and added tests to bring the branch coverage 
to 100%.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/cron/quartz/CronJobManagerImpl.java 
28f1ae72aec392d6b2666e8993920106b8e3138f 
  
src/test/java/org/apache/aurora/scheduler/cron/quartz/CronJobManagerImplTest.java
 934e9bb669e6647dfbc2b43f00d036bad19932e5 

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


Testing
---

./graldew -Pq build


Thanks,

Maxim Khutornenko



Re: Review Request 28361: Extract thrift into an API subproject.

2014-11-25 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 25, 2014, 7:39 p.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28361/
 ---
 
 (Updated Nov. 25, 2014, 7:39 p.m.)
 
 
 Review request for Aurora, Joshua Cohen, Bill Farner, and Zameer Manji.
 
 
 Bugs: AURORA-925
 https://issues.apache.org/jira/browse/AURORA-925
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Extract thrift generation into an api subproject.
 
 
 Diffs
 -
 
   .gitignore ec072d2cf7d9678c59d2f67ec3ab1fda3efd88b7 
   BUILD b6d7ce983dfbb99dd7e26e547a4992a27a48ccdf 
   build-support/python/make-pycharm-virtualenv 
 8f58d4df650892aff987ccfe47a9580023b8cf63 
   build-support/release/make-python-sdists 
 e0d20a19ef1fbc129a882b6368515a3ea41bab3f 
   build-support/thrift/thriftw PRE-CREATION 
   build.gradle 7b35dedb19143b27955c12c4df94ba98ff5f6608 
   buildSrc/src/main/groovy/org/apache/aurora/CoverageReportCheck.groovy 
 f233153fd093cae255c1cb6807cfec6590ba36f9 
   
 buildSrc/src/main/groovy/org/apache/aurora/build/ThriftEntitiesPlugin.groovy 
 PRE-CREATION 
   buildSrc/src/main/groovy/org/apache/aurora/build/ThriftPlugin.groovy 
 PRE-CREATION 
   gradle/wrapper/gradle-wrapper.properties 
 b04300260fd3975ec98a1a1d87b57025e7904c2f 
   settings.gradle 3e9cbfe6e6836f70fb9164f80973f3ebb813ef98 
   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
 4b9281590a9eeb8a8b571b909fd507259abfac44 
   src/main/java/org/apache/aurora/scheduler/http/api/ApiBeta.java 
 c072010ed5a1856a05fa7e6c87b25c073059 
   src/main/python/apache/aurora/admin/BUILD 
 9441e121bf4ea88a7ae286f8cd1cbd0c0ac89e06 
   src/main/python/apache/aurora/client/BUILD 
 48566d99f432e6eb94d1bfdb18277205fd7bb9d8 
   src/main/python/apache/aurora/client/api/BUILD 
 6d2a1bfe8531d800be651ec00518fc5b07a53474 
   src/main/python/apache/aurora/client/cli/BUILD 
 e6627a8a3c501292fdd31ec384320870db702bc2 
   src/main/python/apache/aurora/client/commands/BUILD 
 d146015d70715142618f2653538aca6beb83c1fc 
   src/main/python/apache/aurora/client/hooks/BUILD 
 f46cf650d9b471d08ed2b76652bca5d429f955ee 
   src/main/python/apache/aurora/common/BUILD 
 02ec17ce35c6632df204ea4d1d12e61daf30dd1f 
   src/main/python/apache/aurora/common/auth/BUILD 
 c26d117122d17b2228b637441ce0aa564f5a8a3e 
   src/main/python/apache/aurora/config/BUILD 
 fa40ebdfdecae3eb13878d6f172a591c16507530 
   src/main/python/apache/aurora/config/schema/BUILD 
 157c141bdf968666f31452784967de2a640d1815 
   src/main/python/apache/aurora/executor/BUILD 
 ca4193d31e3e3a71fa45f918058fba40fc911487 
   src/main/python/apache/aurora/executor/common/BUILD 
 d33e14b1cf7be7d115c7fe7741d52896f02f3aed 
   src/main/python/apache/aurora/tools/java/thrift_wrapper_codegen.py 
 d6bb5a120bb6368305ab52d253d25ad2bcfb3e8b 
   src/main/python/apache/thermos/bin/BUILD 
 34e2b3fe1d1a49cc51db8f61339a21ff8e03e0f4 
   src/main/python/apache/thermos/common/BUILD 
 918800b4ccb7bef61249d488ca8a4255168311bb 
   src/main/python/apache/thermos/core/BUILD 
 f362acdc395f1e479bcaf4bc063456abb1fdb0e2 
   src/main/python/apache/thermos/monitoring/BUILD 
 0dad47e6337b7db33dca793f0324892d61e3433a 
   src/main/python/apache/thermos/observer/BUILD 
 b07db90906a06779f5369158469651425fefa1a3 
   src/main/python/apache/thermos/testing/BUILD 
 b96c166e9bc529b783071b5d37b78779a36d06c3 
   src/main/resources/scheduler/assets/scheduler/index.html 
 f4ca07166aee21b8e6b7d3da82454e1b9b132f59 
   src/main/thrift/org/apache/aurora/gen/BUILD  
   src/main/thrift/org/apache/aurora/gen/api.thrift  
   src/main/thrift/org/apache/aurora/gen/internal_rpc.thrift  
   src/main/thrift/org/apache/aurora/gen/storage.thrift  
   src/main/thrift/org/apache/aurora/gen/test.thrift  
   src/main/thrift/org/apache/thermos/BUILD  
   src/main/thrift/org/apache/thermos/thermos_internal.thrift  
   src/test/python/apache/aurora/admin/BUILD 
 101aaa068f2a134f0e846359dc11c7a0ccc28dbb 
   src/test/python/apache/aurora/client/api/BUILD 
 f46ef695decd9b91112b9c933f6220efaa5a0bd3 
   src/test/python/apache/aurora/client/commands/BUILD 
 000eafa95802d6cc835cae7c6f68016645dfe0f1 
   src/test/python/apache/aurora/common/BUILD 
 3933c4616e1df667e7b2ce79e1a6df4c62ca73cf 
   src/test/python/apache/aurora/config/BUILD 
 551595ec6268046817cb1f183d8b0c0af03f5cba 
   src/test/python/apache/aurora/executor/BUILD 
 23a93fdb50c2492d4d8f4613796ff1723e3659fa 
   src/test/python/apache/aurora/executor/common/BUILD 
 318e66d477bbf75d5e36ffe4bc70294da34b4965 
 
 Diff: https://reviews.apache.org/r/28361/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 ./pants src/test/python:all
 
 
 Thanks

Review Request 28450: Fixing admin query command

2014-11-25 Thread Maxim Khutornenko

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

Review request for Aurora and Bill Farner.


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


Repository: aurora


Description
---

Changing the way query is constructed to avoid Invalid JobKey error.


Diffs
-

  src/main/python/apache/aurora/client/commands/admin.py 
9719a581d69e75dc72e8f56ff12758cf9702271b 
  src/test/python/apache/aurora/client/commands/test_admin.py 
7dd61cdd6735bd0f274722249276d60084b4dd93 

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


Testing
---

./pants src/test/python:all


Thanks,

Maxim Khutornenko



Re: Review Request 28350: Add cron replace command.

2014-11-24 Thread Maxim Khutornenko

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


Discarding this in favor of an upserting cron schedule command. Will send a 
new diff to fix help/messaging.

- Maxim Khutornenko


On Nov. 22, 2014, 12:54 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 22, 2014, 12:54 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
   src/test/python/apache/aurora/client/cli/util.py 
 0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28193: Prevent Aurora from creating zero sized Executor tasks.

2014-11-21 Thread Maxim Khutornenko

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



src/main/java/org/apache/aurora/scheduler/ResourceSlot.java
https://reviews.apache.org/r/28193/#comment104640

tabbing is off



src/main/java/org/apache/aurora/scheduler/configuration/Resources.java
https://reviews.apache.org/r/28193/#comment104644

This is only used in tests outside of this class. Consider reverting to 
private.



src/main/java/org/apache/aurora/scheduler/configuration/Resources.java
https://reviews.apache.org/r/28193/#comment104647

+1 on moving it closer to its only consumer. That's a general guideline we 
follow everywhere.



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104649

Not related to your change but consider renaming it to something different 
(e.g. ExecutorSettings) to avoid naming collision with the thrift object.



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104651

-100MB looks like negative resource and is confusing.



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104660

Why not MIN_EXECUTOR_RESOURCES? We normally abstract out from the process 
framework concept in the scheduler code.



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104654

Any justification for the min resources chosen similar to the above?



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104655

Convert to // for inline comments.



src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
https://reviews.apache.org/r/28193/#comment104665

Unless I am missing something, all you need to do here is to make sure 
neither containerResources nor executorResources is less than min. Can you do 
something like:
finalTaskResources = Resources.maxElements(containerResources, 
MIN_TASK_RESOURCES);

and replace .addAllResources(MIN_THERMOS_RESOURCES.toResourceList()) with
.addAllResources(Resources.maxElements(executorOverhead, 
MIN_THERMOS_RESOURCES))?


- Maxim Khutornenko


On Nov. 21, 2014, 5:01 a.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28193/
 ---
 
 (Updated Nov. 21, 2014, 5:01 a.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-928
 https://issues.apache.org/jira/browse/AURORA-928
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Mesos rejects tasks and executors that are zero sized. This patch 
 reconfigures Aurora to ensure no zero sized tasks and executors are created.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/ResourceSlot.java 
 ed60447c798a97daceda4a3bba6ee9bcdcaedd0f 
   src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java 
 40b652c679d8e340f585e28cbed066335d9d760d 
   src/main/java/org/apache/aurora/scheduler/configuration/Resources.java 
 65c4b526c89a4d5607af4424ebe49bb48e296ae9 
   src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java 
 bb227fd86f7c4c692f6ae2aef1c15a94913354b7 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 899416fceae498353880012b8a93491cff461064 
   src/test/java/org/apache/aurora/scheduler/configuration/ResourcesTest.java 
 d6febb8998e05257cabe8d193cefa0b6c79f197e 
   
 src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java 
 953c1edb6802d8983ab324aa56361e5c8fbe2e68 
 
 Diff: https://reviews.apache.org/r/28193/diff/
 
 
 Testing
 ---
 
 ./gradlew clean build -Pq
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 28310: Extract a cluster state abstraction from PreemptorImpl.

2014-11-21 Thread Maxim Khutornenko

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

Ship it!



src/main/java/org/apache/aurora/scheduler/async/Preemptor.java
https://reviews.apache.org/r/28310/#comment104668

newline?



src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java
https://reviews.apache.org/r/28310/#comment104669

Reads awkward. Was this supposed to be a TODO?


- Maxim Khutornenko


On Nov. 21, 2014, 6:28 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28310/
 ---
 
 (Updated Nov. 21, 2014, 6:28 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This is to pull out the bits that will be cached for performance improvements.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/app/AppModule.java 
 19bf162586b90329e764cacf992df37ca68b0dc0 
   src/main/java/org/apache/aurora/scheduler/async/AsyncModule.java 
 4e37f4c9c8d4cde477a96a9b8cca7a075f170919 
   src/main/java/org/apache/aurora/scheduler/async/Preemptor.java 
 97d5d13fcb686c7199ccf92ddab04931d6d5ab57 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 f247ccfb115d4daa10fd4ca46750f708a093791b 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 PRE-CREATION 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterState.java
  PRE-CREATION 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModule.java
  PRE-CREATION 
   src/test/java/org/apache/aurora/scheduler/async/AsyncModuleTest.java 
 962aff8f4fa590935773c9fe90b1a6f59bc1c51f 
   src/test/java/org/apache/aurora/scheduler/async/PreemptorImplTest.java 
 69108cf93e8478b54b0292c27ff56074448ec793 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
 17f2d77bd1a143a9388ff1f52fa8edfcdfe08d91 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
 012804a72fddb3e05f01d7e556cd577c07614ede 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterStateTest.java
  PRE-CREATION 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModuleTest.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28310/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28310: Extract a cluster state abstraction from PreemptorImpl.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 6:48 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/async/Preemptor.java, line 301
  https://reviews.apache.org/r/28310/diff/3/?file=772285#file772285line301
 
  newline?
 
 Bill Farner wrote:
 Not sure what you're requesting here.  Where would you like to see a 
 newline?

This line is a continuation, so I expected a newline after it as per our 
guidelines.


- Maxim


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


On Nov. 21, 2014, 7:42 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28310/
 ---
 
 (Updated Nov. 21, 2014, 7:42 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Zameer Manji.
 
 
 Bugs: AURORA-121
 https://issues.apache.org/jira/browse/AURORA-121
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This is to pull out the bits that will be cached for performance improvements.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/app/AppModule.java 
 19bf162586b90329e764cacf992df37ca68b0dc0 
   src/main/java/org/apache/aurora/scheduler/async/AsyncModule.java 
 4e37f4c9c8d4cde477a96a9b8cca7a075f170919 
   src/main/java/org/apache/aurora/scheduler/async/Preemptor.java 
 97d5d13fcb686c7199ccf92ddab04931d6d5ab57 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 f247ccfb115d4daa10fd4ca46750f708a093791b 
   src/main/java/org/apache/aurora/scheduler/async/preemptor/ClusterState.java 
 PRE-CREATION 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterState.java
  PRE-CREATION 
   
 src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModule.java
  PRE-CREATION 
   src/test/java/org/apache/aurora/scheduler/async/AsyncModuleTest.java 
 962aff8f4fa590935773c9fe90b1a6f59bc1c51f 
   src/test/java/org/apache/aurora/scheduler/async/PreemptorImplTest.java 
 69108cf93e8478b54b0292c27ff56074448ec793 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
 17f2d77bd1a143a9388ff1f52fa8edfcdfe08d91 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
 012804a72fddb3e05f01d7e556cd577c07614ede 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/LiveClusterStateTest.java
  PRE-CREATION 
   
 src/test/java/org/apache/aurora/scheduler/async/preemptor/PreemptorModuleTest.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/28310/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28193: Prevent Aurora from creating zero sized Executor tasks.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 6:41 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/configuration/Resources.java, 
  line 196
  https://reviews.apache.org/r/28193/diff/2/?file=772028#file772028line196
 
  This is only used in tests outside of this class. Consider reverting to 
  private.
 
 Zameer Manji wrote:
 I think using this constant in tests makes the tests a bit simplier. I 
 have added a '@VisibleForTesting' annotation to signifiy this.

Using @VisibleForTesting is rather an exception when you want to reuse the 
complex definition. You already re-define SOME_EXECUTOR_OVERHEAD for test 
purposes, why not do the same for NO_EXECUTOR_OVERHEAD?


 On Nov. 21, 2014, 6:41 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/configuration/Resources.java, 
  line 406
  https://reviews.apache.org/r/28193/diff/2/?file=772028#file772028line406
 
  +1 on moving it closer to its only consumer. That's a general guideline 
  we follow everywhere.
 
 Zameer Manji wrote:
 I really think it should belong with the Resources class because it is 
 equally as useful as .sum in my opinion. If you disagree I will move it 
 closer to the consumer.

You can always move it there when there is a use case. Until then, it's better 
follow our style any open up only those things that are used in more than one 
place.


 On Nov. 21, 2014, 6:41 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java, line 
  94
  https://reviews.apache.org/r/28193/diff/2/?file=772029#file772029line94
 
  Why not MIN_EXECUTOR_RESOURCES? We normally abstract out from the 
  process framework concept in the scheduler code.
 
 Zameer Manji wrote:
 These minimum values are for thermos. Another executor might require more 
 resources to function.

Did not we want to eliminate it completely though but Mesos did not let us do 
that? I suggest we just use a default and abstract MIN_EXECUTOR_RESOURCES and 
address the real need to differentiate when/if it comes up. Also, when 
https://reviews.apache.org/r/28345/ lands, the 100MB will become more like 0.5 
MB, so it clearly feels like an arbitrary Mesos workaround rather than a true 
MIN enforcement.


 On Nov. 21, 2014, 6:41 p.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java, 
  lines 166-173
  https://reviews.apache.org/r/28193/diff/2/?file=772029#file772029line166
 
  Unless I am missing something, all you need to do here is to make sure 
  neither containerResources nor executorResources is less than min. Can you 
  do something like:
  finalTaskResources = Resources.maxElements(containerResources, 
  MIN_TASK_RESOURCES);
  
  and replace .addAllResources(MIN_THERMOS_RESOURCES.toResourceList()) 
  with
  .addAllResources(Resources.maxElements(executorOverhead, 
  MIN_THERMOS_RESOURCES))?
 
 Zameer Manji wrote:
 I would always like to allocate MIN_THERMOS_RESOURCES for the executor. 
 What you are proposing will make it possible to allocate more CPU or RAM. 
 This is a change in behaviour from before where we were always allocated a 
 fixed amount for the executor.
 
 I can change it to this if you insist but I prefer to allocate a fixed 
 amount for the executor.

Valid point. Though given the randomness of the applied MIN requirement I am 
not sure how important it is. I would go with a more readable and simple 
approach here. Your call.


- Maxim


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


On Nov. 21, 2014, 8:34 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28193/
 ---
 
 (Updated Nov. 21, 2014, 8:34 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-928
 https://issues.apache.org/jira/browse/AURORA-928
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Mesos rejects tasks and executors that are zero sized. This patch 
 reconfigures Aurora to ensure no zero sized tasks and executors are created.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/ResourceSlot.java 
 ed60447c798a97daceda4a3bba6ee9bcdcaedd0f 
   src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java 
 40b652c679d8e340f585e28cbed066335d9d760d 
   src/main/java/org/apache/aurora/scheduler/configuration/Resources.java 
 65c4b526c89a4d5607af4424ebe49bb48e296ae9 
   src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java 
 bb227fd86f7c4c692f6ae2aef1c15a94913354b7 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 899416fceae498353880012b8a93491cff461064 
   src/test/java/org/apache

Re: Review Request 28345: Move thermos_runner out of the apache.aurora.executor package.

2014-11-21 Thread Maxim Khutornenko

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

Ship it!


it also makes thermos_runner.pex 566k instead of 70MB - awesome!

- Maxim Khutornenko


On Nov. 21, 2014, 7:52 p.m., Brian Wickman wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28345/
 ---
 
 (Updated Nov. 21, 2014, 7:52 p.m.)
 
 
 Review request for Aurora, Bhuvan Arumugam, Joshua Cohen, and Maxim 
 Khutornenko.
 
 
 Bugs: AURORA-823
 https://issues.apache.org/jira/browse/AURORA-823
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Move thermos_runner out of the apache.aurora.executor package.
 
 The drawback of having it in the apache.aurora.executor package is that if we 
 want to build a thermos_runner binary from the apache.aurora.executor 
 distribution, it transitively pulls in mesos.native, making the 
 thermos_runner pex like 70MB.  thermos_runner.pex really only has 
 dependencies within apache.thermos and the thermos_runner exit-code contract 
 is a bit more clear now, so putting it into apache.thermos makes a bit more 
 sense now.  it also makes thermos_runner.pex 566k instead of 70MB.  it also 
 fixes AURORA-823.
 
 
 Diffs
 -
 
   examples/vagrant/aurorabuild.sh 4d51cee1c19ed677e08000f03de1c9050e85832b 
   src/main/python/apache/aurora/executor/BUILD 
 ca4193d31e3e3a71fa45f918058fba40fc911487 
   src/main/python/apache/aurora/executor/bin/BUILD 
 a41cf950b707ac47486b7f869edba1fc9e42 
   src/main/python/apache/aurora/executor/bin/thermos_runner_main.py 
 f61caf038db0be4decc4acfe4a2a378de28be50b 
   src/main/python/apache/aurora/executor/thermos_runner.py 
 e10f43896bda4c3ed3c879168e42e104aff89483 
   src/main/python/apache/aurora/executor/thermos_statuses.py  
   src/main/python/apache/aurora/executor/thermos_task_runner.py 
 9a2faa06325c23c41b64f3d0a1422d849c03f278 
   src/main/python/apache/thermos/bin/BUILD 
 34e2b3fe1d1a49cc51db8f61339a21ff8e03e0f4 
   src/main/python/apache/thermos/common/BUILD 
 918800b4ccb7bef61249d488ca8a4255168311bb 
   src/test/python/apache/aurora/executor/test_thermos_executor.py 
 16a40111da055268f7ab396a3a4ea38176c526a3 
   src/test/python/apache/aurora/executor/test_thermos_task_runner.py 
 4fc9d4b7eced0a5d65d09be6c66e30f555d8734b 
 
 Diff: https://reviews.apache.org/r/28345/diff/
 
 
 Testing
 ---
 
 build-support/jenkins/build.sh
 
 firing off an integration test run right now.
 
 
 Thanks,
 
 Brian Wickman
 




Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko

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

Review request for Aurora, David McLaughlin and Bill Farner.


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


Repository: aurora


Description
---

Implementing aurora cron replace command to close the functionality gap that 
will be created with client updater removal.


Diffs
-

  docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
  docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
  src/main/python/apache/aurora/client/api/__init__.py 
d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
  src/main/python/apache/aurora/client/cli/cron.py 
cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
  src/main/python/apache/aurora/client/cli/update.py 
12774af8bcd1c953fdbc799b0a142c27407d69f5 
  src/test/python/apache/aurora/client/api/test_api.py 
1f4e9fe9111ac88726d7c45b699b3b91438448b6 
  src/test/python/apache/aurora/client/cli/test_cron.py 
c748212febf5867f5f7cc54e34bf91a8890d 
  src/test/python/apache/aurora/client/cli/test_supdate.py 
7637352feea6b07408256158814c05bc17ec14f3 

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


Testing
---

./pants src/test/python:all

tested in vagrant as well


Thanks,

Maxim Khutornenko



Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 11:26 p.m., Kevin Sweeney wrote:
  docs/cron-jobs.md, line 89
  https://reviews.apache.org/r/28350/diff/1/?file=772861#file772861line89
 
  Hold on a sec - why do we have this and cron schedule (see above)?

The cron replace is an atomic convenience command for cron deschedule + 
cron schedule. It finalizes the cron/service split:
job create  cron schedule
job killall  cron deschedule (with caveat that active tasks are not killed)
job update  cron replace


- Maxim


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


On Nov. 21, 2014, 11:14 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 21, 2014, 11:14 p.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 11:34 p.m., David McLaughlin wrote:
  src/test/python/apache/aurora/client/cli/test_cron.py, lines 199-215
  https://reviews.apache.org/r/28350/diff/1/?file=772866#file772866line199
 
  This is an integration test. Can we replace this with a more 
  fine-grained unit test that only tests against the Replace verb you added? 
  There is an example of this for beta-update start in your review. You'll be 
  able to remove the use of mock.patch and the creation of a temporary file 
  if you do.

I am a bit concerned about this spread of different approaches in command 
testing but in this particular case it clearly made it simpler. Done.


- Maxim


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


On Nov. 21, 2014, 11:14 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 21, 2014, 11:14 p.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 11:32 p.m., Bill Farner wrote:
  src/test/python/apache/aurora/client/cli/test_cron.py, lines 218-227
  https://reviews.apache.org/r/28350/diff/1/?file=772866#file772866line218
 
  This block is repeated ~verbatim 4x in this file.  Cleaning up the 
  underlying code to improve testing is probably too high of a bar, but you 
  could at least extract a helper function to minimize the spread.

Obviated by refactoring.


 On Nov. 21, 2014, 11:32 p.m., Bill Farner wrote:
  docs/cron-jobs.md, line 90
  https://reviews.apache.org/r/28350/diff/1/?file=772861#file772861line90
 
  This makes it seem like only the _execution schedule_ is changed by 
  this command, not the template.  Suggest rewording to mkae it more obvious 
  that this will update subsequent cron executions.

Good point. Reworded.


- Maxim


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


On Nov. 21, 2014, 11:14 p.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 21, 2014, 11:14 p.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko

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

(Updated Nov. 22, 2014, 12:54 a.m.)


Review request for Aurora, David McLaughlin and Bill Farner.


Changes
---

CR comments.


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


Repository: aurora


Description
---

Implementing aurora cron replace command to close the functionality gap that 
will be created with client updater removal.


Diffs (updated)
-

  docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
  docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
  src/main/python/apache/aurora/client/api/__init__.py 
d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
  src/main/python/apache/aurora/client/cli/cron.py 
cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
  src/main/python/apache/aurora/client/cli/update.py 
12774af8bcd1c953fdbc799b0a142c27407d69f5 
  src/test/python/apache/aurora/client/api/test_api.py 
1f4e9fe9111ac88726d7c45b699b3b91438448b6 
  src/test/python/apache/aurora/client/cli/test_cron.py 
c748212febf5867f5f7cc54e34bf91a8890d 
  src/test/python/apache/aurora/client/cli/test_supdate.py 
7637352feea6b07408256158814c05bc17ec14f3 
  src/test/python/apache/aurora/client/cli/util.py 
0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 

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


Testing
---

./pants src/test/python:all

tested in vagrant as well


Thanks,

Maxim Khutornenko



Re: Review Request 28193: Prevent Aurora from creating zero sized Executor tasks.

2014-11-21 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 21, 2014, 10:50 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28193/
 ---
 
 (Updated Nov. 21, 2014, 10:50 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-928
 https://issues.apache.org/jira/browse/AURORA-928
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Mesos rejects tasks and executors that are zero sized. This patch 
 reconfigures Aurora to ensure no zero sized tasks and executors are created.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/ResourceSlot.java 
 ed60447c798a97daceda4a3bba6ee9bcdcaedd0f 
   src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java 
 40b652c679d8e340f585e28cbed066335d9d760d 
   src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java 
 bb227fd86f7c4c692f6ae2aef1c15a94913354b7 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 899416fceae498353880012b8a93491cff461064 
   
 src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java 
 953c1edb6802d8983ab324aa56361e5c8fbe2e68 
 
 Diff: https://reviews.apache.org/r/28193/diff/
 
 
 Testing
 ---
 
 ./gradlew clean build -Pq
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 28193: Prevent Aurora from creating zero sized Executor tasks.

2014-11-21 Thread Maxim Khutornenko

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


On master now.

- Maxim Khutornenko


On Nov. 21, 2014, 10:50 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28193/
 ---
 
 (Updated Nov. 21, 2014, 10:50 p.m.)
 
 
 Review request for Aurora, Maxim Khutornenko and Bill Farner.
 
 
 Bugs: AURORA-928
 https://issues.apache.org/jira/browse/AURORA-928
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Mesos rejects tasks and executors that are zero sized. This patch 
 reconfigures Aurora to ensure no zero sized tasks and executors are created.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/ResourceSlot.java 
 ed60447c798a97daceda4a3bba6ee9bcdcaedd0f 
   src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java 
 40b652c679d8e340f585e28cbed066335d9d760d 
   src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java 
 bb227fd86f7c4c692f6ae2aef1c15a94913354b7 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 899416fceae498353880012b8a93491cff461064 
   
 src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java 
 953c1edb6802d8983ab324aa56361e5c8fbe2e68 
 
 Diff: https://reviews.apache.org/r/28193/diff/
 
 
 Testing
 ---
 
 ./gradlew clean build -Pq
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 11:26 p.m., Kevin Sweeney wrote:
  docs/cron-jobs.md, line 89
  https://reviews.apache.org/r/28350/diff/1/?file=772861#file772861line89
 
  Hold on a sec - why do we have this and cron schedule (see above)?
 
 Maxim Khutornenko wrote:
 The cron replace is an atomic convenience command for cron deschedule 
 + cron schedule. It finalizes the cron/service split:
 job create  cron schedule
 job killall  cron deschedule (with caveat that active tasks are not 
 killed)
 job update  cron replace
 
 Kevin Sweeney wrote:
 cron schedule does both job create and job update

What..? I completely forgot that scheduleCronJob actually acts as upsert. 
Should we move the update functionality from it in favor of 
replaceCronTemplate and have our client `cron` commands consistent with `job` 
commands though? I can argue both ways. Any thoughts?


- Maxim


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


On Nov. 22, 2014, 12:54 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 22, 2014, 12:54 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
   src/test/python/apache/aurora/client/cli/util.py 
 0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28350: Add cron replace command.

2014-11-21 Thread Maxim Khutornenko


 On Nov. 21, 2014, 11:26 p.m., Kevin Sweeney wrote:
  docs/cron-jobs.md, line 89
  https://reviews.apache.org/r/28350/diff/1/?file=772861#file772861line89
 
  Hold on a sec - why do we have this and cron schedule (see above)?
 
 Maxim Khutornenko wrote:
 The cron replace is an atomic convenience command for cron deschedule 
 + cron schedule. It finalizes the cron/service split:
 job create  cron schedule
 job killall  cron deschedule (with caveat that active tasks are not 
 killed)
 job update  cron replace
 
 Kevin Sweeney wrote:
 cron schedule does both job create and job update
 
 Maxim Khutornenko wrote:
 What..? I completely forgot that scheduleCronJob actually acts as 
 upsert. Should we move the update functionality from it in favor of 
 replaceCronTemplate and have our client `cron` commands consistent with `job` 
 commands though? I can argue both ways. Any thoughts?
 
 Kevin Sweeney wrote:
 I was completely surprised to learn that when I was writing this document 
 as well.
 
 I'm in favor of leaving the existing behavior as-is and removing any 
 unused endpoints.

There are no unused endpoints yet. The replaceCronTemplate is still used by the 
client updater.


- Maxim


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


On Nov. 22, 2014, 12:54 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28350/
 ---
 
 (Updated Nov. 22, 2014, 12:54 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-921
 https://issues.apache.org/jira/browse/AURORA-921
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Implementing aurora cron replace command to close the functionality gap 
 that will be created with client updater removal.
 
 
 Diffs
 -
 
   docs/clientv2.md 6e69af3837f63321e273f1df7b0f5a1c07505cc7 
   docs/cron-jobs.md 7d04bcd3776bfd85f14e4398c4bc57dfbbdbcc72 
   src/main/python/apache/aurora/client/api/__init__.py 
 d12132f8ee64a390c9b5b4c9ab26b5e4b2b1bb59 
   src/main/python/apache/aurora/client/cli/cron.py 
 cfd957cb99fb1c0bff04f0c91969a66faaf3b6f2 
   src/main/python/apache/aurora/client/cli/update.py 
 12774af8bcd1c953fdbc799b0a142c27407d69f5 
   src/test/python/apache/aurora/client/api/test_api.py 
 1f4e9fe9111ac88726d7c45b699b3b91438448b6 
   src/test/python/apache/aurora/client/cli/test_cron.py 
 c748212febf5867f5f7cc54e34bf91a8890d 
   src/test/python/apache/aurora/client/cli/test_supdate.py 
 7637352feea6b07408256158814c05bc17ec14f3 
   src/test/python/apache/aurora/client/cli/util.py 
 0ec74e675aaabc7ac0cb28e02f5b8534570b7a49 
 
 Diff: https://reviews.apache.org/r/28350/diff/
 
 
 Testing
 ---
 
 ./pants src/test/python:all
 
 tested in vagrant as well
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28361: Extract thrift into an API subproject.

2014-11-21 Thread Maxim Khutornenko

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



build-support/thrift/thriftw
https://reviews.apache.org/r/28361/#comment104795

License header?



build-support/thrift/thriftw
https://reviews.apache.org/r/28361/#comment104796

I don't see where EXPECTED_THRIFT_VERSION is used.



build.gradle
https://reviews.apache.org/r/28361/#comment104793

whitespaces?



build.gradle
https://reviews.apache.org/r/28361/#comment104794

revert or remove



buildSrc/src/main/groovy/org/apache/aurora/build/ThriftEntitiesPlugin.groovy
https://reviews.apache.org/r/28361/#comment104797

This is also defined in build.gradle. Any reason it has to be in both 
places?



buildSrc/src/main/groovy/org/apache/aurora/build/ThriftEntitiesPlugin.groovy
https://reviews.apache.org/r/28361/#comment104798

same here


- Maxim Khutornenko


On Nov. 22, 2014, 1:35 a.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28361/
 ---
 
 (Updated Nov. 22, 2014, 1:35 a.m.)
 
 
 Review request for Aurora, Joshua Cohen, Bill Farner, and Zameer Manji.
 
 
 Bugs: AURORA-925
 https://issues.apache.org/jira/browse/AURORA-925
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Extract thrift generation into an api subproject.
 
 
 Diffs
 -
 
   .gitignore ec072d2cf7d9678c59d2f67ec3ab1fda3efd88b7 
   BUILD b6d7ce983dfbb99dd7e26e547a4992a27a48ccdf 
   build-support/python/make-pycharm-virtualenv 
 8f58d4df650892aff987ccfe47a9580023b8cf63 
   build-support/release/make-python-sdists 
 e0d20a19ef1fbc129a882b6368515a3ea41bab3f 
   build-support/thrift/thriftw PRE-CREATION 
   build.gradle 6894ceb7055c0491dce1c869fad0371d432f6540 
   buildSrc/src/main/groovy/org/apache/aurora/CoverageReportCheck.groovy 
 f233153fd093cae255c1cb6807cfec6590ba36f9 
   
 buildSrc/src/main/groovy/org/apache/aurora/build/ThriftEntitiesPlugin.groovy 
 PRE-CREATION 
   buildSrc/src/main/groovy/org/apache/aurora/build/ThriftPlugin.groovy 
 PRE-CREATION 
   gradle/wrapper/gradle-wrapper.properties 
 b04300260fd3975ec98a1a1d87b57025e7904c2f 
   settings.gradle PRE-CREATION 
   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
 4b9281590a9eeb8a8b571b909fd507259abfac44 
   src/main/java/org/apache/aurora/scheduler/http/api/ApiBeta.java 
 c072010ed5a1856a05fa7e6c87b25c073059 
   src/main/python/apache/aurora/admin/BUILD 
 9441e121bf4ea88a7ae286f8cd1cbd0c0ac89e06 
   src/main/python/apache/aurora/client/BUILD 
 48566d99f432e6eb94d1bfdb18277205fd7bb9d8 
   src/main/python/apache/aurora/client/api/BUILD 
 6d2a1bfe8531d800be651ec00518fc5b07a53474 
   src/main/python/apache/aurora/client/cli/BUILD 
 e6627a8a3c501292fdd31ec384320870db702bc2 
   src/main/python/apache/aurora/client/commands/BUILD 
 d146015d70715142618f2653538aca6beb83c1fc 
   src/main/python/apache/aurora/client/hooks/BUILD 
 f46cf650d9b471d08ed2b76652bca5d429f955ee 
   src/main/python/apache/aurora/common/BUILD 
 02ec17ce35c6632df204ea4d1d12e61daf30dd1f 
   src/main/python/apache/aurora/common/auth/BUILD 
 c26d117122d17b2228b637441ce0aa564f5a8a3e 
   src/main/python/apache/aurora/config/BUILD 
 fa40ebdfdecae3eb13878d6f172a591c16507530 
   src/main/python/apache/aurora/config/schema/BUILD 
 157c141bdf968666f31452784967de2a640d1815 
   src/main/python/apache/aurora/executor/BUILD 
 ca4193d31e3e3a71fa45f918058fba40fc911487 
   src/main/python/apache/aurora/executor/common/BUILD 
 d33e14b1cf7be7d115c7fe7741d52896f02f3aed 
   src/main/python/apache/aurora/tools/java/thrift_wrapper_codegen.py 
 d6bb5a120bb6368305ab52d253d25ad2bcfb3e8b 
   src/main/python/apache/thermos/bin/BUILD 
 34e2b3fe1d1a49cc51db8f61339a21ff8e03e0f4 
   src/main/python/apache/thermos/common/BUILD 
 918800b4ccb7bef61249d488ca8a4255168311bb 
   src/main/python/apache/thermos/core/BUILD 
 f362acdc395f1e479bcaf4bc063456abb1fdb0e2 
   src/main/python/apache/thermos/monitoring/BUILD 
 0dad47e6337b7db33dca793f0324892d61e3433a 
   src/main/python/apache/thermos/observer/BUILD 
 b07db90906a06779f5369158469651425fefa1a3 
   src/main/python/apache/thermos/testing/BUILD 
 b96c166e9bc529b783071b5d37b78779a36d06c3 
   src/main/thrift/org/apache/aurora/gen/BUILD  
   src/main/thrift/org/apache/aurora/gen/api.thrift  
   src/main/thrift/org/apache/aurora/gen/internal_rpc.thrift  
   src/main/thrift/org/apache/aurora/gen/storage.thrift  
   src/main/thrift/org/apache/aurora/gen/test.thrift  
   src/main/thrift/org/apache/thermos/BUILD  
   src/main/thrift/org/apache/thermos/thermos_internal.thrift  
   src/test/python/apache/aurora/admin/BUILD 
 101aaa068f2a134f0e846359dc11c7a0ccc28dbb 
   src/test/python/apache/aurora/client/api/BUILD

Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-20 Thread Maxim Khutornenko

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


@ReviewBot retry

- Maxim Khutornenko


On Nov. 20, 2014, 3:01 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 20, 2014, 3:01 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 f247ccfb115d4daa10fd4ca46750f708a093791b 
   src/main/java/org/apache/aurora/scheduler/events/PubsubEvent.java 
 4821a7890b77ccb04c10bee6d8b4b9e7216940cc 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintMatcher.java 
 cc8c5b81baf0cf05d7ac04f69ad2834fa9438aac 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 723e7ab70b8bfd930154dcce385cd1e1d599cf9f 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cf3bb644008274672c77753b94f4d50c99a1a49b 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
 aaedb3b5ec2cb27550449435efa8f335c6a9baad 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 12ea4c67350c2992f59bacd21a99d1413b60b757 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  d408ec0f7781f65d5b5f215eced5d6255e53b0dd 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  d1a70661122802ecfdd8efa2ced567685c08995f 
   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
 b60b004adbd6753ec6fef125fd70286be5071c56 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  168290af9f84750e66dca69cf056dacb5f38aaa3 
 
 Diff: https://reviews.apache.org/r/27705/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 Verified new stats in vagrant.
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-20 Thread Maxim Khutornenko

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


@ReviewBot retry - last attempt

- Maxim Khutornenko


On Nov. 20, 2014, 3:01 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 20, 2014, 3:01 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 f247ccfb115d4daa10fd4ca46750f708a093791b 
   src/main/java/org/apache/aurora/scheduler/events/PubsubEvent.java 
 4821a7890b77ccb04c10bee6d8b4b9e7216940cc 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintMatcher.java 
 cc8c5b81baf0cf05d7ac04f69ad2834fa9438aac 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 723e7ab70b8bfd930154dcce385cd1e1d599cf9f 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cf3bb644008274672c77753b94f4d50c99a1a49b 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
 aaedb3b5ec2cb27550449435efa8f335c6a9baad 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 12ea4c67350c2992f59bacd21a99d1413b60b757 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  d408ec0f7781f65d5b5f215eced5d6255e53b0dd 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  d1a70661122802ecfdd8efa2ced567685c08995f 
   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
 b60b004adbd6753ec6fef125fd70286be5071c56 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  168290af9f84750e66dca69cf056dacb5f38aaa3 
 
 Diff: https://reviews.apache.org/r/27705/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 Verified new stats in vagrant.
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 28306: Return an iterable of frame chunks.

2014-11-20 Thread Maxim Khutornenko

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



src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java
https://reviews.apache.org/r/28306/#comment104522

Mind commenting on the algorithm here? Why the magic -2?


- Maxim Khutornenko


On Nov. 21, 2014, 12:54 a.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28306/
 ---
 
 (Updated Nov. 21, 2014, 12:54 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-930
 https://issues.apache.org/jira/browse/AURORA-930
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Stream frame chunks instead of preallocating them.
 
 This avoids allocating an entire additional snapshot worth of heap during 
 entry serialization, reducing overall heap impact of the serializer from 
 2*sizeof(serialized-entry) to sizeof(serialized-entry)+chunkSize.
 
 Further optimizations out-of-scope for this change:
 
 * Make the returned iterator mutate a fixed-size buffer (for GC pressure 
 avoidance).
 * Change the log format so that FrameHeader doesn't need to know the size and 
 checksum of the serialized data ahead-of-time (maybe write it as a trailer).
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java 
 f4fa1cb740633ced529c1b5fd9f18abba8944571 
   
 src/main/java/org/apache/aurora/scheduler/storage/log/StreamManagerImpl.java 
 cb95d8996a934751745f423b79279266d73b7722 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 c90389433d81dd72756c659736e38fd9f66fcb35 
 
 Diff: https://reviews.apache.org/r/28306/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 
 Thanks,
 
 Kevin Sweeney
 




Re: Review Request 28306: Return an iterable of frame chunks.

2014-11-20 Thread Maxim Khutornenko


 On Nov. 21, 2014, 1:09 a.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java, 
  line 92
  https://reviews.apache.org/r/28306/diff/1/?file=771713#file771713line92
 
  Mind commenting on the algorithm here? Why the magic -2?
 
 Kevin Sweeney wrote:
 Not sure what I'd say there that doesn't risk contradicting the code 
 below - we don't usually comment loop variables and the old version had the 
 same amount of commenting.

I just find it harder to follow when I see anything less than -1 as the initial 
condition. Why not starting with -1 (to account for the header) and then 
increment i at the end of computeNext()?


- Maxim


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


On Nov. 21, 2014, 1:10 a.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28306/
 ---
 
 (Updated Nov. 21, 2014, 1:10 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-930
 https://issues.apache.org/jira/browse/AURORA-930
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Stream frame chunks instead of preallocating them.
 
 This avoids allocating an entire additional snapshot worth of heap during 
 entry serialization, reducing overall heap impact of the serializer from 
 2*sizeof(serialized-entry) to sizeof(serialized-entry)+chunkSize.
 
 Further optimizations out-of-scope for this change:
 
 * Make the returned iterator mutate a fixed-size buffer (for GC pressure 
 avoidance).
 * Change the log format so that FrameHeader doesn't need to know the size and 
 checksum of the serialized data ahead-of-time (maybe write it as a trailer).
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java 
 f4fa1cb740633ced529c1b5fd9f18abba8944571 
   
 src/main/java/org/apache/aurora/scheduler/storage/log/StreamManagerImpl.java 
 cb95d8996a934751745f423b79279266d73b7722 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 c90389433d81dd72756c659736e38fd9f66fcb35 
 
 Diff: https://reviews.apache.org/r/28306/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 
 Thanks,
 
 Kevin Sweeney
 




Re: Review Request 28306: Return an iterable of frame chunks.

2014-11-20 Thread Maxim Khutornenko


 On Nov. 21, 2014, 1:09 a.m., Maxim Khutornenko wrote:
  src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java, 
  line 92
  https://reviews.apache.org/r/28306/diff/1/?file=771713#file771713line92
 
  Mind commenting on the algorithm here? Why the magic -2?
 
 Kevin Sweeney wrote:
 Not sure what I'd say there that doesn't risk contradicting the code 
 below - we don't usually comment loop variables and the old version had the 
 same amount of commenting.
 
 Maxim Khutornenko wrote:
 I just find it harder to follow when I see anything less than -1 as the 
 initial condition. Why not starting with -1 (to account for the header) and 
 then increment i at the end of computeNext()?
 
 Kevin Sweeney wrote:
 Each branch short-circuits so I'd have to have a result intermediate 
 value. I don't find that more readable
 
 ```java
 byte[] result;
 if (i == -1) {
   result = header;
 } else if (...) {
   result = encode(...);
 } else {
   return endOfFile();
 }
 
 i++;
 return result;
 ```

I actually find it more readable as your if-else-if-else eliminates the need to 
short-circuit. Anyway, just a nit that forced me to pause for awhile.


- Maxim


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


On Nov. 21, 2014, 1:10 a.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28306/
 ---
 
 (Updated Nov. 21, 2014, 1:10 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-930
 https://issues.apache.org/jira/browse/AURORA-930
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Stream frame chunks instead of preallocating them.
 
 This avoids allocating an entire additional snapshot worth of heap during 
 entry serialization, reducing overall heap impact of the serializer from 
 2*sizeof(serialized-entry) to sizeof(serialized-entry)+chunkSize.
 
 Further optimizations out-of-scope for this change:
 
 * Make the returned iterator mutate a fixed-size buffer (for GC pressure 
 avoidance).
 * Change the log format so that FrameHeader doesn't need to know the size and 
 checksum of the serialized data ahead-of-time (maybe write it as a trailer).
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java 
 f4fa1cb740633ced529c1b5fd9f18abba8944571 
   
 src/main/java/org/apache/aurora/scheduler/storage/log/StreamManagerImpl.java 
 cb95d8996a934751745f423b79279266d73b7722 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 c90389433d81dd72756c659736e38fd9f66fcb35 
 
 Diff: https://reviews.apache.org/r/28306/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 
 Thanks,
 
 Kevin Sweeney
 




Re: Review Request 28306: Return an iterable of frame chunks.

2014-11-20 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 21, 2014, 1:10 a.m., Kevin Sweeney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28306/
 ---
 
 (Updated Nov. 21, 2014, 1:10 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Bill Farner.
 
 
 Bugs: AURORA-930
 https://issues.apache.org/jira/browse/AURORA-930
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Stream frame chunks instead of preallocating them.
 
 This avoids allocating an entire additional snapshot worth of heap during 
 entry serialization, reducing overall heap impact of the serializer from 
 2*sizeof(serialized-entry) to sizeof(serialized-entry)+chunkSize.
 
 Further optimizations out-of-scope for this change:
 
 * Make the returned iterator mutate a fixed-size buffer (for GC pressure 
 avoidance).
 * Change the log format so that FrameHeader doesn't need to know the size and 
 checksum of the serialized data ahead-of-time (maybe write it as a trailer).
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/storage/log/EntrySerializer.java 
 f4fa1cb740633ced529c1b5fd9f18abba8944571 
   
 src/main/java/org/apache/aurora/scheduler/storage/log/StreamManagerImpl.java 
 cb95d8996a934751745f423b79279266d73b7722 
   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
 c90389433d81dd72756c659736e38fd9f66fcb35 
 
 Diff: https://reviews.apache.org/r/28306/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 
 
 Thanks,
 
 Kevin Sweeney
 




Re: Review Request 28097: Remove ReadWriteLock from MemStorage, remove Storage#weaklyConsistentRead.

2014-11-19 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 19, 2014, 11:41 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28097/
 ---
 
 (Updated Nov. 19, 2014, 11:41 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Bugs: AURORA-929
 https://issues.apache.org/jira/browse/AURORA-929
 
 
 Repository: aurora
 
 
 Description
 ---
 
 See updated class javadoc in `Storage` for new behavior description.  
 Ultimately we're accepting the risk of reading uncommitted writes 
 (specifically in `TaskStore` and `JobStore`).  In practice this should 
 generally be exceedingly rare, as most writes are atomic to one store anyway, 
 and for those that are not (such as rescheduling a task), the window should 
 be O(µs) long.
 
 Once `DbStorage` owns all of the stores, we have a global knob for 
 transaction isolation: 
 http://mybatis.github.io/mybatis-3/java-api.html#sqlSessions (search that 
 page for `TransactionIsolationLevel`).
 
 Without the ReadWriteLock in play, there is no longer a need for 
 `weaklyConsistentRead`, so i've removed that.
 
 
 Diffs
 -
 
   3rdparty/python/BUILD 63ae77f4632db158109e8d562488ce4e84da0438 
   build.gradle f4b4e0d28962b6a1d5802ab9fcd6b4d49afbf360 
   src/main/java/org/apache/aurora/auth/SessionValidator.java 
 eeebb78901a6c33e08ceb8e675c91f0b5f44bcbc 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/GcExecutorLauncher.java 
 e02921df3a217aa2678e91a8bebe6a3708dbc9c3 
   src/main/java/org/apache/aurora/scheduler/async/KillRetry.java 
 d6b7fabe6642944e9fda87c5588029c5bb32c025 
   src/main/java/org/apache/aurora/scheduler/async/Preemptor.java 
 ff26c49729646ffe052cb0a993b9984ae96a89ac 
   src/main/java/org/apache/aurora/scheduler/async/RescheduleCalculator.java 
 ca54c9aa321c831abdbdb8bc1f8c06a0bff95ee2 
   src/main/java/org/apache/aurora/scheduler/async/TaskHistoryPruner.java 
 58d074b491dab2e2e0ce8a8a57e4ebdaf0984e73 
   
 src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
  8cf845f3622392a65216e0c29084965c7c64075d 
   
 src/main/java/org/apache/aurora/scheduler/configuration/SanitizedConfiguration.java
  4eb4437b91906ae191dd105474e84ba5f40cf52e 
   src/main/java/org/apache/aurora/scheduler/cron/SanitizedCronJob.java 
 babbf4203af6f405d4193d6feaa749232e553ae9 
   src/main/java/org/apache/aurora/scheduler/cron/quartz/AuroraCronJob.java 
 84e37e49fabc7ac6bfa2967787cb6abb6ce4af5d 
   
 src/main/java/org/apache/aurora/scheduler/cron/quartz/CronJobManagerImpl.java 
 8e2d3d92c3404f9b24b802687c2d7faeeb27d318 
   src/main/java/org/apache/aurora/scheduler/http/Maintenance.java 
 be8a1fff2db77414dd04637af4a8183810b66845 
   src/main/java/org/apache/aurora/scheduler/http/Mname.java 
 883f954e5dc99311fb701d52dd5d737a50f23276 
   src/main/java/org/apache/aurora/scheduler/http/Quotas.java 
 5f3cce330a9ec7eb3bdfb3512791d918d4c9 
   src/main/java/org/apache/aurora/scheduler/http/Slaves.java 
 0ea462f5d1abbb9eec457205e1b9acca9976027a 
   src/main/java/org/apache/aurora/scheduler/http/StructDump.java 
 8147d545dce3082d63f693c9620e3c769258d9e4 
   src/main/java/org/apache/aurora/scheduler/mesos/SchedulerDriverService.java 
 88150e564e70bf02b62c1c7477d126e98dd91437 
   src/main/java/org/apache/aurora/scheduler/quota/QuotaManager.java 
 e38407ec487d511fb05142cbeda955ec5a6ba4ec 
   src/main/java/org/apache/aurora/scheduler/sla/MetricCalculator.java 
 149bb33568d67fffdee944bf676199e7108b0c0d 
   src/main/java/org/apache/aurora/scheduler/state/LockManagerImpl.java 
 f167290bf99b76ccc049eb51fe95ccfce940d078 
   src/main/java/org/apache/aurora/scheduler/state/MaintenanceController.java 
 a835eaabb047ede5833ca80f43a0cb1bee01d142 
   src/main/java/org/apache/aurora/scheduler/stats/ResourceCounter.java 
 79d12b0dd7959b5443ffce43d9ebdb79135718bb 
   
 src/main/java/org/apache/aurora/scheduler/storage/CallOrderEnforcingStorage.java
  0d02207d7bda46bcc84d2e7328a8c500ad9a5384 
   src/main/java/org/apache/aurora/scheduler/storage/ReadWriteLockManager.java 
 4e6d68b039bb140509b1261f25e7b49457bfd2be 
   src/main/java/org/apache/aurora/scheduler/storage/Storage.java 
 682bca881969d24ece40ab83356f1bebb77feabd 
   src/main/java/org/apache/aurora/scheduler/storage/backup/Recovery.java 
 4744dc9f202969906113ccb610bf17c94d188c43 
   
 src/main/java/org/apache/aurora/scheduler/storage/backup/TemporaryStorage.java
  503bdfeb2cefccfdeb151190b04ce9ce445f47b1 
   src/main/java/org/apache/aurora/scheduler/storage/db/DbStorage.java

Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-19 Thread Maxim Khutornenko


 On Nov. 19, 2014, 10:51 p.m., Bill Farner wrote:
  src/main/java/org/apache/aurora/scheduler/TaskVars.java, line 89
  https://reviews.apache.org/r/27705/diff/4/?file=764617#file764617line89
 
  This should be the only dynamic one, right?  Rack/host limit?  Value 
  constraints can be considered static.

Ah, good catch, reodered names to go alphabetically but did not change the 
values.


- Maxim


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


On Nov. 15, 2014, 12:15 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 15, 2014, 12:15 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 6bfa3ac425ed3045fa60d1b0ca547e9bf3cde37a 
   src/main/java/org/apache/aurora/scheduler/events/PubsubEvent.java 
 4821a7890b77ccb04c10bee6d8b4b9e7216940cc 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintFilter.java 
 3839083f27ca5d4b93406152559b58b04e912a10 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c1c5f26723f1eac3000e09e061b4582f922fded6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cc6b53b3265253f76c1e954c0108aa5936f5cc36 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
 aaedb3b5ec2cb27550449435efa8f335c6a9baad 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 12ea4c67350c2992f59bacd21a99d1413b60b757 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  94f0a179b786649775899f855f7c1a0caab7290f 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  e113eba1f304279b5ee3d70db1d1ea558efd63ac 
   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
 b60b004adbd6753ec6fef125fd70286be5071c56 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  608903268a0a0d67711bfdc81d2e5b29c335ead2 
 
 Diff: https://reviews.apache.org/r/27705/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 Verified new stats in vagrant.
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-19 Thread Maxim Khutornenko


 On Nov. 19, 2014, 10:51 p.m., Bill Farner wrote:
  src/main/java/org/apache/aurora/scheduler/TaskVars.java, line 252
  https://reviews.apache.org/r/27705/diff/4/?file=764617#file764617line252
 
  I don't have strong data to back this up, but i'm concerned about the 
  performance impact here.  In a large/busy cluster, this could be invoked 
  O(100k) times per second.  Can you avoid the Set creation?  Maybe instead 
  just loop and use two flags?
  
  To combat this, we really need to move the nearest fit/miss calculation 
  to the publisher end (which would, unfortunately, break these stats).  For 
  now, i think it makes sense to merely be cognizant of the call frequency.

Refactored to not use any new object creation.


- Maxim


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


On Nov. 15, 2014, 12:15 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 15, 2014, 12:15 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 6bfa3ac425ed3045fa60d1b0ca547e9bf3cde37a 
   src/main/java/org/apache/aurora/scheduler/events/PubsubEvent.java 
 4821a7890b77ccb04c10bee6d8b4b9e7216940cc 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintFilter.java 
 3839083f27ca5d4b93406152559b58b04e912a10 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c1c5f26723f1eac3000e09e061b4582f922fded6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cc6b53b3265253f76c1e954c0108aa5936f5cc36 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
 aaedb3b5ec2cb27550449435efa8f335c6a9baad 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 12ea4c67350c2992f59bacd21a99d1413b60b757 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  94f0a179b786649775899f855f7c1a0caab7290f 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  e113eba1f304279b5ee3d70db1d1ea558efd63ac 
   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
 b60b004adbd6753ec6fef125fd70286be5071c56 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  608903268a0a0d67711bfdc81d2e5b29c335ead2 
 
 Diff: https://reviews.apache.org/r/27705/diff/
 
 
 Testing
 ---
 
 ./gradlew -Pq build
 Verified new stats in vagrant.
 
 
 Thanks,
 
 Maxim Khutornenko
 




Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-19 Thread Maxim Khutornenko

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

(Updated Nov. 20, 2014, 3:01 a.m.)


Review request for Aurora, Bill Farner and Zameer Manji.


Changes
---

CR comments and rebasing.


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


Repository: aurora


Description
---

Adding @Timed to trace scheduling latencies and Veto counters per type.


Diffs (updated)
-

  src/main/java/org/apache/aurora/scheduler/TaskVars.java 
cf8f7584afee758c527798914181049051aef0d8 
  src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
  src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
f247ccfb115d4daa10fd4ca46750f708a093791b 
  src/main/java/org/apache/aurora/scheduler/events/PubsubEvent.java 
4821a7890b77ccb04c10bee6d8b4b9e7216940cc 
  src/main/java/org/apache/aurora/scheduler/filter/ConstraintMatcher.java 
cc8c5b81baf0cf05d7ac04f69ad2834fa9438aac 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
723e7ab70b8bfd930154dcce385cd1e1d599cf9f 
  src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
cf3bb644008274672c77753b94f4d50c99a1a49b 
  src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
87203690f09456ac1ca5e9da2b82826d60cbd723 
  src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
aaedb3b5ec2cb27550449435efa8f335c6a9baad 
  src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
12ea4c67350c2992f59bacd21a99d1413b60b757 
  
src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
 d408ec0f7781f65d5b5f215eced5d6255e53b0dd 
  
src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java 
d1a70661122802ecfdd8efa2ced567685c08995f 
  src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
b60b004adbd6753ec6fef125fd70286be5071c56 
  
src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
 168290af9f84750e66dca69cf056dacb5f38aaa3 

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


Testing
---

./gradlew -Pq build
Verified new stats in vagrant.


Thanks,

Maxim Khutornenko



Re: Review Request 28026: Add more test coverage to SchedulerThriftInterface.

2014-11-18 Thread Maxim Khutornenko


 On Nov. 14, 2014, 1:48 a.m., Zameer Manji wrote:
  src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java,
   line 1787
  https://reviews.apache.org/r/28026/diff/1/?file=763222#file763222line1787
 
  Can you file a JIRA for this?

This is now tracked by https://issues.apache.org/jira/browse/AURORA-937


- Maxim


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


On Nov. 14, 2014, 1:30 a.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28026/
 ---
 
 (Updated Nov. 14, 2014, 1:30 a.m.)
 
 
 Review request for Aurora, David McLaughlin and Zameer Manji.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 This brings SchedulerThriftInterface to 99% instruction coverage and 96% 
 branch coverage.  The remaining pieces are legitimately difficult to capture.
 
 I also uncovered a few minor bugs along the way, most noteworthy being AOP 
 interceptor ordering leading to the standard API response not always being 
 applied.
 
 Additionally, i removed a bunch of unnecessary exception handling that is now 
 done by an AOP interceptor.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/auth/SessionValidator.java 
 eeebb78901a6c33e08ceb8e675c91f0b5f44bcbc 
   src/main/java/org/apache/aurora/scheduler/storage/backup/Recovery.java 
 4744dc9f202969906113ccb610bf17c94d188c43 
   
 src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
  b2b66acee9c0789f3660469d6d504b4510af5e79 
   src/main/java/org/apache/aurora/scheduler/thrift/Util.java 
 18e2bdfab6406761d7e7cbcec26d12fb28441fe0 
   src/main/java/org/apache/aurora/scheduler/thrift/aop/AopModule.java 
 dca855c522d21924821fc47e636da39689aec4b7 
   
 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java
  5c9ea6cf4eb4d99d94f5d61e784dd7c9c480798c 
 
 Diff: https://reviews.apache.org/r/28026/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28103: Simplify Preemptor code, encapsulate parameters used there and in SchedulingFilter.

2014-11-17 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 16, 2014, 10:29 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28103/
 ---
 
 (Updated Nov. 16, 2014, 10:29 p.m.)
 
 
 Review request for Aurora, David McLaughlin and Zameer Manji.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Simplify Preemptor code, encapsulate fields used there and in 
 SchedulingFilter.
 
 A lot of this addressing Law of Demeter violations, such as accepting 
 `IAssignedTask` when only `ITaskConfig` and task ID were needed.  There are 
 also (what i consider) readability improvements in `SchedulingFilterImpl` and 
 `PreemptorImpl`.
 
 The broader goal here is to simplify the code usedin scheduling, hopefully to 
 make forthcoming scheduling performance improvements less complicated.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/async/Preemptor.java 
 ff26c49729646ffe052cb0a993b9984ae96a89ac 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 6bfa3ac425ed3045fa60d1b0ca547e9bf3cde37a 
   src/main/java/org/apache/aurora/scheduler/base/Tasks.java 
 a2997f518f90eac34cb6fbb1104240b823d45f22 
   
 src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java
  8cf845f3622392a65216e0c29084965c7c64075d 
   
 src/main/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilter.java
  ca53303a675be60300cc1b6534164fa6da7ddbd7 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintFilter.java 
 3839083f27ca5d4b93406152559b58b04e912a10 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c1c5f26723f1eac3000e09e061b4582f922fded6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cc6b53b3265253f76c1e954c0108aa5936f5cc36 
   src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java 
 4abc7ba36c547624af51fabc0983099efe5798ea 
   src/main/java/org/apache/aurora/scheduler/stats/ResourceCounter.java 
 79d12b0dd7959b5443ffce43d9ebdb79135718bb 
   src/test/java/org/apache/aurora/scheduler/async/PreemptorImplTest.java 
 8b0367ec99701084ce0cf55229a363c4b0b66b8f 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 
 9bc6a7535bf69dbc19771aa1834aeb04f42eea48 
   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 
 d1bc9bfe987b83356483cf1fb04aef2eb51eb141 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  94f0a179b786649775899f855f7c1a0caab7290f 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  e113eba1f304279b5ee3d70db1d1ea558efd63ac 
   src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java 
 a8a70b65c6f91371b9afad4dd3806a7c86fba04f 
 
 Diff: https://reviews.apache.org/r/28103/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bill Farner
 




Re: Review Request 28097: Remove ReadWriteLock from MemStorage, remove Storage#weaklyConsistentRead.

2014-11-17 Thread Maxim Khutornenko

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


I don't see ReadWriteLockManager removal in this diff. It was only used in mem 
storage AFAICT.


src/main/java/org/apache/aurora/scheduler/storage/Storage.java
https://reviews.apache.org/r/28097/#comment103650

typo


- Maxim Khutornenko


On Nov. 16, 2014, 10:43 p.m., Bill Farner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28097/
 ---
 
 (Updated Nov. 16, 2014, 10:43 p.m.)
 
 
 Review request for Aurora, Kevin Sweeney and Maxim Khutornenko.
 
 
 Bugs: AURORA-929
 https://issues.apache.org/jira/browse/AURORA-929
 
 
 Repository: aurora
 
 
 Description
 ---
 
 See updated class javadoc in `Storage` for new behavior description.  
 Ultimately we're accepting the risk of reading uncommitted writes 
 (specifically in `TaskStore` and `JobStore`).  In practice this should 
 generally be exceedingly rare, as most writes are atomic to one store anyway, 
 and for those that are not (such as rescheduling a task), the window should 
 be O(µs) long.
 
 Once `DbStorage` owns all of the stores, we have a global knob for 
 transaction isolation: 
 http://mybatis.github.io/mybatis-3/java-api.html#sqlSessions (search that 
 page for `TransactionIsolationLevel`).
 
 Without the ReadWriteLock in play, there is no longer a need for 
 `weaklyConsistentRead`, so i've removed that.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/GcExecutorLauncher.java 
 e02921df3a217aa2678e91a8bebe6a3708dbc9c3 
   src/main/java/org/apache/aurora/scheduler/async/KillRetry.java 
 d6b7fabe6642944e9fda87c5588029c5bb32c025 
   src/main/java/org/apache/aurora/scheduler/async/Preemptor.java 
 ff26c49729646ffe052cb0a993b9984ae96a89ac 
   src/main/java/org/apache/aurora/scheduler/async/RescheduleCalculator.java 
 ca54c9aa321c831abdbdb8bc1f8c06a0bff95ee2 
   src/main/java/org/apache/aurora/scheduler/async/TaskHistoryPruner.java 
 58d074b491dab2e2e0ce8a8a57e4ebdaf0984e73 
   src/main/java/org/apache/aurora/scheduler/cron/quartz/AuroraCronJob.java 
 84e37e49fabc7ac6bfa2967787cb6abb6ce4af5d 
   
 src/main/java/org/apache/aurora/scheduler/cron/quartz/CronJobManagerImpl.java 
 8e2d3d92c3404f9b24b802687c2d7faeeb27d318 
   src/main/java/org/apache/aurora/scheduler/http/Maintenance.java 
 be8a1fff2db77414dd04637af4a8183810b66845 
   src/main/java/org/apache/aurora/scheduler/http/Mname.java 
 883f954e5dc99311fb701d52dd5d737a50f23276 
   src/main/java/org/apache/aurora/scheduler/http/Quotas.java 
 5f3cce330a9ec7eb3bdfb3512791d918d4c9 
   src/main/java/org/apache/aurora/scheduler/http/Slaves.java 
 0ea462f5d1abbb9eec457205e1b9acca9976027a 
   src/main/java/org/apache/aurora/scheduler/http/StructDump.java 
 8147d545dce3082d63f693c9620e3c769258d9e4 
   src/main/java/org/apache/aurora/scheduler/mesos/SchedulerDriverService.java 
 88150e564e70bf02b62c1c7477d126e98dd91437 
   src/main/java/org/apache/aurora/scheduler/quota/QuotaManager.java 
 e38407ec487d511fb05142cbeda955ec5a6ba4ec 
   src/main/java/org/apache/aurora/scheduler/sla/MetricCalculator.java 
 149bb33568d67fffdee944bf676199e7108b0c0d 
   src/main/java/org/apache/aurora/scheduler/state/LockManagerImpl.java 
 f167290bf99b76ccc049eb51fe95ccfce940d078 
   src/main/java/org/apache/aurora/scheduler/state/MaintenanceController.java 
 a835eaabb047ede5833ca80f43a0cb1bee01d142 
   src/main/java/org/apache/aurora/scheduler/stats/ResourceCounter.java 
 79d12b0dd7959b5443ffce43d9ebdb79135718bb 
   
 src/main/java/org/apache/aurora/scheduler/storage/CallOrderEnforcingStorage.java
  0d02207d7bda46bcc84d2e7328a8c500ad9a5384 
   src/main/java/org/apache/aurora/scheduler/storage/Storage.java 
 682bca881969d24ece40ab83356f1bebb77feabd 
   
 src/main/java/org/apache/aurora/scheduler/storage/backup/TemporaryStorage.java
  503bdfeb2cefccfdeb151190b04ce9ce445f47b1 
   src/main/java/org/apache/aurora/scheduler/storage/db/DbStorage.java 
 40487e5461da8062555e4e40ccb1c146ab665c5f 
   src/main/java/org/apache/aurora/scheduler/storage/log/LogStorage.java 
 45ea50fff10c5ff10db3f225cdbbb0204f056d31 
   src/main/java/org/apache/aurora/scheduler/storage/log/LogStorageModule.java 
 73348f3ef0d7452497e14a3889f5c20da04e5455 
   
 src/main/java/org/apache/aurora/scheduler/storage/log/SnapshotStoreImpl.java 
 66ff56714bfd1fc429a67d9da862172df5072639 
   src/main/java/org/apache/aurora/scheduler/storage/mem/MemStorage.java 
 2cc76dc1583c43cb528e78275b8a4ad23b8529d2 
   
 src/main/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterface.java
  f0b49758236a40670931864e600cbc8375581919 
   
 src/test

Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-14 Thread Maxim Khutornenko


 On Nov. 14, 2014, 2:24 a.m., Bill Farner wrote:
  src/main/java/org/apache/aurora/scheduler/TaskVars.java, line 226
  https://reviews.apache.org/r/27705/diff/2/?file=763034#file763034line226
 
  To get the data we want, some extra analysis is needed.  Specifically - 
  if we want to figure out how often a scheduling attempt is vetoed _only_ 
  for static reasons (e.g. insufficient resources), these stats will lack 
  signal.
  
  Instead, we probably want two counters:
  - scheduling_veto_static
  - scheduling_veto_dynamic
  
  Does that make sense?
 
 Maxim Khutornenko wrote:
 I don't see how more granular data would prevent us from aggregating into 
 static/dynamic groups. However, having aggregate metrics instead will make it 
 impossible to do any further analysis when needed. Why not going the more 
 specific route instead? I would have hard time figuring out what 
 scheduling_veto_static means without digging through the sources, whereas 
 something like scheduling_veto_INSUFFICIENT_RESOURCES would immediately 
 make sense by itself.
 
 Bill Farner wrote:
 The problem is that you can't discern when a task didn't match due to 
 _only_ static reasons.  Relevant code in `SchedulingFilterImpl`:
 
 return ImmutableSet.Vetobuilder()
 .addAll(getConstraintFilter(attributeAggregate, 
 attributes).apply(task))
 .addAll(getResourceVetoes(offer, task))
 .build();
 
 On the other end when you incrmeent counters:
 
 for (Veto veto : event.getVetoes()) {
   counters.getUnchecked(vetoStatName(veto)).increment();
 }
 
 At this point, you might get vetoes like: `insufficient CPU`, 
 `insufficient RAM`, `insufficient ports`, `limit not satisfied: host`.
 You'll end up with these counter deltas:
 
 `INSUFFICIENT_RESOURCES 3`
 `LIMIT_NOT_SATISFIED 1`
 
 As a result, i don't see how we could look at the stats and convince 
 ourselves which optimization has the greatest payoff, since a single 
 scheduling round affects multiple counters disproportionately.

Isn't it the same problem with the aggregate counters? I.e. in the above 
example we would still see static=1 (or 3?) and dynamic=1.

To address your concern of excessive counting, how about maintaining unique 
veto type counters instead? Something like this:
```java
ListMultimapVetoType, Veto index = Multimaps.index(event.getVetoes(), 
VETO_TO_VETO_TYPE);
for (VetoType vetoType : index.keys()) {
  counters.getUnchecked(vetoStatName(vetoType)).increment();
}
```
For the above example, it would produce:

scheduling_veto_INSUFFICIENT_RESOURCES 1
scheduling_veto_LIMIT_NOT_SATISFIED  1


- Maxim


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


On Nov. 14, 2014, 12:30 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 14, 2014, 12:30 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 e2ba8b8fe978a58d1edcd01963ea020e54529353 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintFilter.java 
 3839083f27ca5d4b93406152559b58b04e912a10 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c1c5f26723f1eac3000e09e061b4582f922fded6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cc6b53b3265253f76c1e954c0108aa5936f5cc36 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats/CachedCounters.java 
 aaedb3b5ec2cb27550449435efa8f335c6a9baad 
   src/test/java/org/apache/aurora/scheduler/TaskVarsTest.java 
 12ea4c67350c2992f59bacd21a99d1413b60b757 
   
 src/test/java/org/apache/aurora/scheduler/events/NotifyingSchedulingFilterTest.java
  94f0a179b786649775899f855f7c1a0caab7290f 
   
 src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java
  e113eba1f304279b5ee3d70db1d1ea558efd63ac 
   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 
 b60b004adbd6753ec6fef125fd70286be5071c56 
   
 src

Re: Review Request 28048: Fix task_util dependency and add it to all target.

2014-11-14 Thread Maxim Khutornenko

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

Ship it!


Ship It!

- Maxim Khutornenko


On Nov. 14, 2014, 7 p.m., Zameer Manji wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/28048/
 ---
 
 (Updated Nov. 14, 2014, 7 p.m.)
 
 
 Review request for Aurora and Maxim Khutornenko.
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Fix task_util dependency and add it to all target.
 
 
 Diffs
 -
 
   src/test/python/apache/aurora/client/api/BUILD 
 b4f08c6192e6bf6b38665197e98db7235751ae86 
 
 Diff: https://reviews.apache.org/r/28048/diff/
 
 
 Testing
 ---
 
 Before:
 [tw-mbp-zmanji aurora (master)]$ ./pants 
 src/test/python/apache/aurora/client/api:task_util
 Build operating on top level addresses: 
 set([BuildFileAddress(/Users/zmanji/workspace/aurora/src/test/python/apache/aurora/client/api/BUILD,
  task_util)])
  test session starts 
 
 platform darwin -- Python 2.7.5 -- py-1.4.26 -- pytest-2.6.4
 plugins: cov, timeout
 collected 0 items / 1 errors
 
 == ERRORS 
 ===
  ERROR collecting 
 src/test/python/apache/aurora/client/api/test_task_util.py 
 
 src/test/python/apache/aurora/client/api/test_task_util.py:22: in module
 from ..api.api_util import SchedulerThriftApiSpec
 src/test/python/apache/aurora/client/api/api_util.py:1: in module
 from apache.aurora.client.api.scheduler_client import SchedulerProxy
 E   ImportError: No module named scheduler_client
 == 1 error in 0.18 
 seconds ==
 src.test.python.apache.aurora.client.api.task_util
   .   FAILURE
 
 After:
 [tw-mbp-zmanji aurora (fix-task-util-test)]$ ./pants 
 src/test/python/apache/aurora/client/api:task_util
 Build operating on top level addresses: 
 set([BuildFileAddress(/Users/zmanji/workspace/aurora/src/test/python/apache/aurora/client/api/BUILD,
  task_util)])
  test session starts 
 
 platform darwin -- Python 2.7.5 -- py-1.4.26 -- pytest-2.6.4
 plugins: cov, timeout
 collected 2 items
 
 src/test/python/apache/aurora/client/api/test_task_util.py ..
 
 = 2 passed in 0.45 
 seconds ==
 src.test.python.apache.aurora.client.api.task_util
   .   SUCCESS
 
 
 Thanks,
 
 Zameer Manji
 




Re: Review Request 27705: Adding instrumentation into the scheduling pipeline.

2014-11-14 Thread Maxim Khutornenko


 On Nov. 14, 2014, 2:24 a.m., Bill Farner wrote:
  src/main/java/org/apache/aurora/scheduler/TaskVars.java, line 226
  https://reviews.apache.org/r/27705/diff/2/?file=763034#file763034line226
 
  To get the data we want, some extra analysis is needed.  Specifically - 
  if we want to figure out how often a scheduling attempt is vetoed _only_ 
  for static reasons (e.g. insufficient resources), these stats will lack 
  signal.
  
  Instead, we probably want two counters:
  - scheduling_veto_static
  - scheduling_veto_dynamic
  
  Does that make sense?
 
 Maxim Khutornenko wrote:
 I don't see how more granular data would prevent us from aggregating into 
 static/dynamic groups. However, having aggregate metrics instead will make it 
 impossible to do any further analysis when needed. Why not going the more 
 specific route instead? I would have hard time figuring out what 
 scheduling_veto_static means without digging through the sources, whereas 
 something like scheduling_veto_INSUFFICIENT_RESOURCES would immediately 
 make sense by itself.
 
 Bill Farner wrote:
 The problem is that you can't discern when a task didn't match due to 
 _only_ static reasons.  Relevant code in `SchedulingFilterImpl`:
 
 return ImmutableSet.Vetobuilder()
 .addAll(getConstraintFilter(attributeAggregate, 
 attributes).apply(task))
 .addAll(getResourceVetoes(offer, task))
 .build();
 
 On the other end when you incrmeent counters:
 
 for (Veto veto : event.getVetoes()) {
   counters.getUnchecked(vetoStatName(veto)).increment();
 }
 
 At this point, you might get vetoes like: `insufficient CPU`, 
 `insufficient RAM`, `insufficient ports`, `limit not satisfied: host`.
 You'll end up with these counter deltas:
 
 `INSUFFICIENT_RESOURCES 3`
 `LIMIT_NOT_SATISFIED 1`
 
 As a result, i don't see how we could look at the stats and convince 
 ourselves which optimization has the greatest payoff, since a single 
 scheduling round affects multiple counters disproportionately.
 
 Maxim Khutornenko wrote:
 Isn't it the same problem with the aggregate counters? I.e. in the above 
 example we would still see static=1 (or 3?) and dynamic=1.
 
 To address your concern of excessive counting, how about maintaining 
 unique veto type counters instead? Something like this:
 ```java
 ListMultimapVetoType, Veto index = 
 Multimaps.index(event.getVetoes(), VETO_TO_VETO_TYPE);
 for (VetoType vetoType : index.keys()) {
   counters.getUnchecked(vetoStatName(vetoType)).increment();
 }
 ```
 For the above example, it would produce:
 
 scheduling_veto_INSUFFICIENT_RESOURCES 1
 scheduling_veto_LIMIT_NOT_SATISFIED  1

Discussed with Bill offline. There is more logic to it. It's not just about 
gouping metrics but rather reporting the group when ALL of the Vetos issued 
fall into the same group. For example: 
- insufficient RAM, limit not satisfied - only static vetos - increment 
static counter;
- constraint mismatch, insufficient RAM - mixed static and dynamic vetos - 
increment mixed counter;
- constraint mismatch - only dynamic vetos - increment dynamic counter;


- Maxim


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


On Nov. 14, 2014, 12:30 a.m., Maxim Khutornenko wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27705/
 ---
 
 (Updated Nov. 14, 2014, 12:30 a.m.)
 
 
 Review request for Aurora, Bill Farner and Zameer Manji.
 
 
 Bugs: AURORA-914
 https://issues.apache.org/jira/browse/AURORA-914
 
 
 Repository: aurora
 
 
 Description
 ---
 
 Adding @Timed to trace scheduling latencies and Veto counters per type.
 
 
 Diffs
 -
 
   src/main/java/org/apache/aurora/scheduler/TaskVars.java 
 cf8f7584afee758c527798914181049051aef0d8 
   src/main/java/org/apache/aurora/scheduler/async/OfferQueue.java 
 d2682cd910d248c897e691bcb4c8a3a6f1aec2d2 
   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java 
 e2ba8b8fe978a58d1edcd01963ea020e54529353 
   src/main/java/org/apache/aurora/scheduler/filter/ConstraintFilter.java 
 3839083f27ca5d4b93406152559b58b04e912a10 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 
 c1c5f26723f1eac3000e09e061b4582f922fded6 
   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java 
 cc6b53b3265253f76c1e954c0108aa5936f5cc36 
   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java 
 87203690f09456ac1ca5e9da2b82826d60cbd723 
   src/main/java/org/apache/aurora/scheduler/stats

<    1   2   3   4   5   6   7   8   9   10   >