date:20170110

Re: Review Request 54957: Add option to not retry api calls to the scheduler.

2017-01-10 Thread Stephan Erb



> On Jan. 5, 2017, 12:54 a.m., Karthik Anantha Padmanabhan wrote:
> > I was going to wrap this up - but how do people feel about making the all 
> > endpoints "idempotent" by the following method ? Inlcude an 
> > "idempotency-token" along as part of the HTTP header. This token is locally 
> > cached for, say, an hour. Every request with the same token will return 
> > simply short circuit and not be processed. The retry logic to transport 
> > layer so that we can transparently add the idempotency tokens.
> 
> Santhosh Kumar Shanmugham wrote:
> Can you explain this in detail? Particularly flesh out the `HTTP headers` 
> (aren't we using a Thrift interface while speaking to the Scheduler?) and the 
> `locally cached` (have the Scheduler cache the `idempotency-token` or on the 
> client?) parts.
> 
> I like this approach better, which can fix the issue across all APIs.
> 
> Karthik Anantha Padmanabhan wrote:
> https://reviews.apache.org/r/55237/ is a WIP for idempotent requests. Yes 
> we still use HTTP as the transport but just stuff the thrift binary in the 
> body of a POST request.

I have to admit going down that route feels a little bit like overkill to me. 
Explicitly flagging the non-retryable operations as proposed by David will also 
get the job done and come with less complexity.


- Stephan


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


On Dec. 22, 2016, 1:06 a.m., Karthik Anantha Padmanabhan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54957/
> ---
> 
> (Updated Dec. 22, 2016, 1:06 a.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Joshua Cohen, Santhosh Kumar 
> Shanmugham, and Zameer Manji.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> This diff adds an option to not retry api calls to the scheduler. For some of 
> the non-idempotent operations we would like to not automatically retry. This 
> patch makes this functionality available only to the `schedule_backup_now` 
> command.
> 
> If there is consensus, this can be added to all commands as well.
> 
> 
> Diffs
> -
> 
>   src/main/python/apache/aurora/admin/admin.py 
> 070c348d2ca5db1edecf832efd9aa5481bddaa4b 
>   src/main/python/apache/aurora/admin/aurora_admin.py 
> fbebbab8c827b5695042d18770d850e31fc38122 
>   src/main/python/apache/aurora/client/api/__init__.py 
> e1dde638bd1d686269fbcd88cb083a52e7f5dbfc 
>   src/main/python/apache/aurora/client/api/scheduler_client.py 
> 9bbfece012e48e0b1752bbefd25c89e04d312cf6 
>   src/test/python/apache/aurora/client/api/test_scheduler_client.py 
> f6018caa4f431e85a9e9ff203ac3d4b6c33f40ef 
> 
> Diff: https://reviews.apache.org/r/54957/diff/
> 
> 
> Testing
> ---
> 
> * Manuall testing
> * ./build-support/jenkins/build.sh passes
> 
> 
> Thanks,
> 
> Karthik Anantha Padmanabhan
> 
>

Re: Review Request 55237: WIP for idempotent api endpoints.

2017-01-10 Thread Karthik Anantha Padmanabhan


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

(Updated Jan. 10, 2017, 11:21 p.m.)


Review request for Aurora and Santhosh Kumar Shanmugham.


Repository: aurora


Description
---

WIP for idempotent requests. The changes are basically the following:

1. In the client we construct a thrift transport based on the requests library. 
A new `TRequestsTransportRetry` adds a http header called `Idempotency-Token`. 
The retry logic is moved here so that retries will use the same idempotency 
token. I use the retry library for exponential backoff
2. In the scheduler `TContentAwareServlet` is provided with a `RequestCache` 
which is nothing but a Guava cache which expires keys after an hour.


Diffs
-

  3rdparty/python/requirements.txt df2db7ac1a1d62465731c057f67000cb589a 
  RELEASE-NOTES.md 90c4793b218f54ad92ab4da5049d5e92c3a104b3 
  src/main/java/org/apache/aurora/scheduler/http/api/ApiModule.java 
e46820952fb6028911bca924169ceade6a134bfc 
  src/main/java/org/apache/aurora/scheduler/http/api/RequestCache.java 
PRE-CREATION 
  src/main/java/org/apache/aurora/scheduler/http/api/TContentAwareServlet.java 
d9df96896d83786596880105968dc7fcdc0168e5 
  src/main/python/apache/aurora/admin/BUILD 
b5d37f718a25d43d7ac07e30f789cf526bdfdcc2 
  src/main/python/apache/aurora/admin/admin.py 
070c348d2ca5db1edecf832efd9aa5481bddaa4b 
  src/main/python/apache/aurora/admin/aurora_admin.py 
fbebbab8c827b5695042d18770d850e31fc38122 
  src/main/python/apache/aurora/client/api/scheduler_client.py 
9bbfece012e48e0b1752bbefd25c89e04d312cf6 
  src/main/python/apache/aurora/common/BUILD 
0e4c51020946dc21953493bd43b944177c444c28 
  src/main/python/apache/aurora/common/transport.py 
f44d13afa06112ff7b03a68cd01e7d9ef9e550ea 
  
src/test/java/org/apache/aurora/scheduler/http/api/TContentAwareServletTests.java
 PRE-CREATION 
  src/test/python/apache/aurora/client/api/test_scheduler_client.py 
f6018caa4f431e85a9e9ff203ac3d4b6c33f40ef 
  src/test/python/apache/aurora/common/test_transport.py 
c3d35d278a68db603954ad1e3cf26c6359ae3926 

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


Testing
---

Works locally. 

Not good for a review , this is just work in progress.


Thanks,

Karthik Anantha Padmanabhan

Re: Review Request 55243: AURORA-1868 Evaluate multiple preemption proposals per round

2017-01-10 Thread Stephan Erb


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


Ship it!




Ship It!

- Stephan Erb


On Jan. 6, 2017, 2:17 a.m., Mehrdad Nurolahzade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55243/
> ---
> 
> (Updated Jan. 6, 2017, 2:17 a.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Zameer Manji.
> 
> 
> Bugs: AURORA-1868
> https://issues.apache.org/jira/browse/AURORA-1868
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> `TaskScheduler` makes an attempt to preempt already identified candidates 
> through `Preemptor` when it fails to schedule one or more tasks. However, 
> `Preemptor` currently evaluates only one proposal per invocation. A proposal 
> may get vetoed at this point by scheduling filters. If a proposal fails 
> validation the task group might get penalized by `TaskGroups` to give 
> `PendingTaskProcessor` some time to find new preemption candidates; despite 
> the fact that another proposal may already exist in `slotCache`. This penalty 
> might result in expiration of existing proposals in `slotCache`, hence 
> slowing down the overall preemption process.
> 
> This patch modifies `Preemptor` so that it evaluates all existing preemption 
> proposals before giving up.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/preemptor/Preemptor.java 
> 7d2903a47dacfc35f9e547ccb6c5896efe3e013f 
>   src/test/java/org/apache/aurora/scheduler/preemptor/PreemptorImplTest.java 
> 40c42b1b3aa63797da8dea61732b49155034fea2 
> 
> Diff: https://reviews.apache.org/r/55243/diff/
> 
> 
> Testing
> ---
> 
> ```
> $ ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> ...
> 
> *** OK (All tests passed) ***
> 
> mesos-master start/running, process 12228
> + RETCODE=0
> + restore_netrc
> + mv /home/vagrant/.netrc.bak /home/vagrant/.netrc
> + true
> Connection to 127.0.0.1 closed.
> 
> real  26m20.055s
> user  0m1.412s
> sys   0m0.705s
> ```
> 
> 
> Thanks,
> 
> Mehrdad Nurolahzade
> 
>

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

2017-01-10 Thread Stephan Erb


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


Ship it!




LGTM


src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorModule.java (lines 
64 - 65)


We only have a reservation once we have found a match. How about calling 
this 'searched' rather than 'processed'?


- Stephan Erb


On Jan. 9, 2017, 10:40 p.m., Mehrdad Nurolahzade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55357/
> ---
> 
> (Updated Jan. 9, 2017, 10:40 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Joshua Cohen, Stephan Erb, and 
> Zameer Manji.
> 
> 
> Bugs: AURORA-1867
> https://issues.apache.org/jira/browse/AURORA-1867
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> To be fair, PendingTaskProcessor interleaves tasks from different groups. 
> However, this fairness comes at the price of increasing reservation time. 
> Even if reservations are being made for the same task group, the processor 
> would still restart iterating through slaves for each task instance. This 
> results in reevaluating all slaves already rejected in a previous search 
> before it finds a new viable candidate.
> 
> This patch improves `PendingTaskProcessor` performance by reducing slave 
> search/evaluation time, at the cost of reduced fairness. 
> `PendingTaskProcessor` now does reservation for a configurable maximum of _N_ 
> candidates per task group in each iteration over the list of slaves.
> 
> 
> Diffs
> -
> 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 
> fa37236e68657b539b182519b9d46d96d5b0953a 
>   
> src/main/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessor.java 
> f59f3fd8959b1ba3726b55a2943fb9228a049ac5 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorMetrics.java 
> 67822cafbe89f4798b4ea6da3856663cc4872798 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorModule.java 
> 23d1c120657d5cb9d294a80c63e8a04512d361ca 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessorTest.java
>  d11ae5883f2a00dca4c4b36f0ab58ea95c7ecb2e 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PreemptorModuleTest.java 
> 67b6d69e3ddd1028dfe9ff451b171cd888674920 
> 
> Diff: https://reviews.apache.org/r/55357/diff/
> 
> 
> Testing
> ---
> 
> As is, the cluster setup in our existing preemption benchmark does not 
> reflect the improvements resulting from this patch. Currently, all existing 
> victims can be preempted, therefore all `PendingTaskProcessor` has to is look 
> at the next slave.
> 
> ```
> BEFORE
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  75.386 ± 2.984  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  74.584 ± 2.598  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  79.731 ± 2.182  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  66.386 ± 1.833  ops/s
> 
> AFTER
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  78.266 ± 3.290  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  76.743 ± 2.073  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  75.343 ± 1.943  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  68.284 ± 2.413  ops/s
> ```
> 
> I need to further imprpve the cluster setup for this benchmark to reflect the 
> improvements in the patch. A more representative cluster setup would be one 
> in which only a subset of potential victims pass 
> `PreemptionVictimFilter.filterPreemptionVictims()` test.
> 
> 
> Thanks,
> 
> Mehrdad Nurolahzade
> 
>

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

2017-01-10 Thread Aurora ReviewBot


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


Ship it!




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

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

- Aurora ReviewBot


On Jan. 9, 2017, 9:40 p.m., Mehrdad Nurolahzade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55357/
> ---
> 
> (Updated Jan. 9, 2017, 9:40 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Joshua Cohen, Stephan Erb, and 
> Zameer Manji.
> 
> 
> Bugs: AURORA-1867
> https://issues.apache.org/jira/browse/AURORA-1867
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> To be fair, PendingTaskProcessor interleaves tasks from different groups. 
> However, this fairness comes at the price of increasing reservation time. 
> Even if reservations are being made for the same task group, the processor 
> would still restart iterating through slaves for each task instance. This 
> results in reevaluating all slaves already rejected in a previous search 
> before it finds a new viable candidate.
> 
> This patch improves `PendingTaskProcessor` performance by reducing slave 
> search/evaluation time, at the cost of reduced fairness. 
> `PendingTaskProcessor` now does reservation for a configurable maximum of _N_ 
> candidates per task group in each iteration over the list of slaves.
> 
> 
> Diffs
> -
> 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 
> fa37236e68657b539b182519b9d46d96d5b0953a 
>   
> src/main/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessor.java 
> f59f3fd8959b1ba3726b55a2943fb9228a049ac5 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorMetrics.java 
> 67822cafbe89f4798b4ea6da3856663cc4872798 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorModule.java 
> 23d1c120657d5cb9d294a80c63e8a04512d361ca 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessorTest.java
>  d11ae5883f2a00dca4c4b36f0ab58ea95c7ecb2e 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PreemptorModuleTest.java 
> 67b6d69e3ddd1028dfe9ff451b171cd888674920 
> 
> Diff: https://reviews.apache.org/r/55357/diff/
> 
> 
> Testing
> ---
> 
> As is, the cluster setup in our existing preemption benchmark does not 
> reflect the improvements resulting from this patch. Currently, all existing 
> victims can be preempted, therefore all `PendingTaskProcessor` has to is look 
> at the next slave.
> 
> ```
> BEFORE
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  75.386 ± 2.984  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  74.584 ± 2.598  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  79.731 ± 2.182  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  66.386 ± 1.833  ops/s
> 
> AFTER
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  78.266 ± 3.290  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  76.743 ± 2.073  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  75.343 ± 1.943  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  68.284 ± 2.413  ops/s
> ```
> 
> I need to further imprpve the cluster setup for this benchmark to reflect the 
> improvements in the patch. A more representative cluster setup would be one 
> in which only a subset of potential victims pass 
> `PreemptionVictimFilter.filterPreemptionVictims()` test.
> 
> 
> Thanks,
> 
> Mehrdad Nurolahzade
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Stephan Erb


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


Ship it!




Ship It!

- Stephan Erb


On Jan. 10, 2017, 7 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 7 p.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>   src/main/python/apache/aurora/executor/common/sandbox.py 
> 9d6e73c4221302c56596ef3591bdeab41c81535e 
>   src/test/python/apache/aurora/executor/common/test_sandbox.py 
> a441d2a60e413395b74b62445846e3871784e729 
>   src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
> 438eb0f03128d21b3201d0a843adebe09422c75e 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> 46309371a33d26bdd467b5fa131634354be2a978 
> 
> Diff: https://reviews.apache.org/r/55347/diff/
> 
> 
> Testing
> ---
> 
> ./build-support/jenkins/build.sh
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Aurora ReviewBot


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


Ship it!




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

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

- Aurora ReviewBot


On Jan. 10, 2017, 6 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 6 p.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>   src/main/python/apache/aurora/executor/common/sandbox.py 
> 9d6e73c4221302c56596ef3591bdeab41c81535e 
>   src/test/python/apache/aurora/executor/common/test_sandbox.py 
> a441d2a60e413395b74b62445846e3871784e729 
>   src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
> 438eb0f03128d21b3201d0a843adebe09422c75e 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> 46309371a33d26bdd467b5fa131634354be2a978 
> 
> Diff: https://reviews.apache.org/r/55347/diff/
> 
> 
> Testing
> ---
> 
> ./build-support/jenkins/build.sh
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

2017-01-10 Thread Stephan Erb


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



@ReviewBot retry

- Stephan Erb


On Jan. 9, 2017, 10:40 p.m., Mehrdad Nurolahzade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55357/
> ---
> 
> (Updated Jan. 9, 2017, 10:40 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Joshua Cohen, Stephan Erb, and 
> Zameer Manji.
> 
> 
> Bugs: AURORA-1867
> https://issues.apache.org/jira/browse/AURORA-1867
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> To be fair, PendingTaskProcessor interleaves tasks from different groups. 
> However, this fairness comes at the price of increasing reservation time. 
> Even if reservations are being made for the same task group, the processor 
> would still restart iterating through slaves for each task instance. This 
> results in reevaluating all slaves already rejected in a previous search 
> before it finds a new viable candidate.
> 
> This patch improves `PendingTaskProcessor` performance by reducing slave 
> search/evaluation time, at the cost of reduced fairness. 
> `PendingTaskProcessor` now does reservation for a configurable maximum of _N_ 
> candidates per task group in each iteration over the list of slaves.
> 
> 
> Diffs
> -
> 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 
> fa37236e68657b539b182519b9d46d96d5b0953a 
>   
> src/main/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessor.java 
> f59f3fd8959b1ba3726b55a2943fb9228a049ac5 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorMetrics.java 
> 67822cafbe89f4798b4ea6da3856663cc4872798 
>   src/main/java/org/apache/aurora/scheduler/preemptor/PreemptorModule.java 
> 23d1c120657d5cb9d294a80c63e8a04512d361ca 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PendingTaskProcessorTest.java
>  d11ae5883f2a00dca4c4b36f0ab58ea95c7ecb2e 
>   
> src/test/java/org/apache/aurora/scheduler/preemptor/PreemptorModuleTest.java 
> 67b6d69e3ddd1028dfe9ff451b171cd888674920 
> 
> Diff: https://reviews.apache.org/r/55357/diff/
> 
> 
> Testing
> ---
> 
> As is, the cluster setup in our existing preemption benchmark does not 
> reflect the improvements resulting from this patch. Currently, all existing 
> victims can be preempted, therefore all `PendingTaskProcessor` has to is look 
> at the next slave.
> 
> ```
> BEFORE
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  75.386 ± 2.984  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  74.584 ± 2.598  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  79.731 ± 2.182  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  66.386 ± 1.833  ops/s
> 
> AFTER
> Benchmark   
> (numPendingTasks)   Mode  Cnt   Score   Error  Units
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>   1  thrpt   10  78.266 ± 3.290  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
>  10  thrpt   10  76.743 ± 2.073  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark
> 100  thrpt   10  75.343 ± 1.943  ops/s
> SchedulingBenchmarks.PreemptorSlotSearchBenchmark.runBenchmark   
> 1000  thrpt   10  68.284 ± 2.413  ops/s
> ```
> 
> I need to further imprpve the cluster setup for this benchmark to reflect the 
> improvements in the patch. A more representative cluster setup would be one 
> in which only a subset of potential victims pass 
> `PreemptionVictimFilter.filterPreemptionVictims()` test.
> 
> 
> Thanks,
> 
> Mehrdad Nurolahzade
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Stephan Erb


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



@ReviewBot retry

- Stephan Erb


On Jan. 10, 2017, 7 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 7 p.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>   src/main/python/apache/aurora/executor/common/sandbox.py 
> 9d6e73c4221302c56596ef3591bdeab41c81535e 
>   src/test/python/apache/aurora/executor/common/test_sandbox.py 
> a441d2a60e413395b74b62445846e3871784e729 
>   src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
> 438eb0f03128d21b3201d0a843adebe09422c75e 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> 46309371a33d26bdd467b5fa131634354be2a978 
> 
> Diff: https://reviews.apache.org/r/55347/diff/
> 
> 
> Testing
> ---
> 
> ./build-support/jenkins/build.sh
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Santhosh Kumar Shanmugham


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


Ship it!




LGTM.

- Santhosh Kumar Shanmugham


On Jan. 10, 2017, 10 a.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 10 a.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>   src/main/python/apache/aurora/executor/common/sandbox.py 
> 9d6e73c4221302c56596ef3591bdeab41c81535e 
>   src/test/python/apache/aurora/executor/common/test_sandbox.py 
> a441d2a60e413395b74b62445846e3871784e729 
>   src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
> 438eb0f03128d21b3201d0a843adebe09422c75e 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> 46309371a33d26bdd467b5fa131634354be2a978 
> 
> Diff: https://reviews.apache.org/r/55347/diff/
> 
> 
> Testing
> ---
> 
> ./build-support/jenkins/build.sh
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Aurora ReviewBot


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



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

  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  INFO] Executor [None]:Reason: test_message
  INFO] Executor [None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
 I0110 18:14:35.522526 17409 executor_base.py:45] Executor 
[None]:Reason: test_message
  INFO] Executor []:Reason: Task initialization failed: 
Task failed: Thermos exited for unknown reason (exit status: 1)
  generated xml file: 
/home/jenkins/jenkins-slave/workspace/AuroraBot/dist/test-results/aaf4d108c31293299a0839bdc404a91802f80937.xml
 
 [1m[31m 1 failed, 775 passed, 7 skipped, 1 warnings in 
298.66 seconds [0m
 
FAILURE


18:15:01 05:42   [complete][31m
   FAILURE[0m


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

- Aurora ReviewBot


On Jan. 10, 2017, 6 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 6 p.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Joshua Cohen



> On Jan. 9, 2017, 7:28 p.m., Stephan Erb wrote:
> > src/main/python/apache/aurora/executor/common/sandbox.py, lines 285-290
> > 
> >
> > This looks suspicious. Creating a directory and then checking it does 
> > not exist.

Fixed.


> On Jan. 9, 2017, 7:28 p.m., Stephan Erb wrote:
> > src/test/python/apache/aurora/executor/common/test_sandbox.py, lines 404-410
> > 
> >
> > With that amount of mocking the test is both hard to understand and 
> > brittle to changes of the production code.
> > 
> > Have you considered extending this 
> > https://github.com/apache/aurora/blob/master/examples/vagrant/upstart/aurora-scheduler.conf#L43
> >  list instead?

Added to startup config and added e2e test as well.


- Joshua


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


On Jan. 10, 2017, 6 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55347/
> ---
> 
> (Updated Jan. 10, 2017, 6 p.m.)
> 
> 
> Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> When testing filesystem isolation internally, we ran into an issue where 
> mounting a regular file into the task filesystem failed with exit code 32 
> since the mount destination did not exist. To account for this, we'll touch 
> an empty file in the taskfs.
> 
> 
> Diffs
> -
> 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> e68a801017ae02e0ed581129e12a645ccc1e35d4 
>   src/main/python/apache/aurora/executor/common/sandbox.py 
> 9d6e73c4221302c56596ef3591bdeab41c81535e 
>   src/test/python/apache/aurora/executor/common/test_sandbox.py 
> a441d2a60e413395b74b62445846e3871784e729 
>   src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
> 438eb0f03128d21b3201d0a843adebe09422c75e 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> 46309371a33d26bdd467b5fa131634354be2a978 
> 
> Diff: https://reviews.apache.org/r/55347/diff/
> 
> 
> Testing
> ---
> 
> ./build-support/jenkins/build.sh
> 
> 
> Thanks,
> 
> Joshua Cohen
> 
>

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

2017-01-10 Thread Joshua Cohen


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

(Updated Jan. 10, 2017, 6 p.m.)


Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb.


Changes
---

- Fix bug when creating directories for mount points.
- Add e2e test.
- Minor cleanup on e2e tests to fix i/o redirection on tear down.


Repository: aurora


Description
---

When testing filesystem isolation internally, we ran into an issue where 
mounting a regular file into the task filesystem failed with exit code 32 since 
the mount destination did not exist. To account for this, we'll touch an empty 
file in the taskfs.


Diffs (updated)
-

  examples/vagrant/upstart/aurora-scheduler.conf 
e68a801017ae02e0ed581129e12a645ccc1e35d4 
  src/main/python/apache/aurora/executor/common/sandbox.py 
9d6e73c4221302c56596ef3591bdeab41c81535e 
  src/test/python/apache/aurora/executor/common/test_sandbox.py 
a441d2a60e413395b74b62445846e3871784e729 
  src/test/sh/org/apache/aurora/e2e/http/http_example.aurora 
438eb0f03128d21b3201d0a843adebe09422c75e 
  src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
46309371a33d26bdd467b5fa131634354be2a978 

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


Testing
---

./build-support/jenkins/build.sh


Thanks,

Joshua Cohen

Re: Review Request 55284: Benchmarking SLA Algorithms

2017-01-10 Thread Mehrdad Nurolahzade


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




src/jmh/java/org/apache/aurora/benchmark/Tasks.java (lines 98 - 105)


I see what you are trying to keep task status and events consistant. But if 
I set the task events first and then set the status then I'll lose the events. 
Also setting status based on event timestamps is rather shaky (all those events 
are likely to have the same timestamp).

So, I would suggest moving the consistency checking logic to `build()` 
method and only verifying that the last event (last element of the `events` 
list) matches the status.


- Mehrdad Nurolahzade


On Jan. 10, 2017, 1 a.m., Reza Motamedi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55284/
> ---
> 
> (Updated Jan. 10, 2017, 1 a.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Mehrdad Nurolahzade, and Santhosh 
> Kumar Shanmugham.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> # Adding SLA benchmarks benchmarks 
> This RB is related to 
> [AURORA-1854](https://issues.apache.org/jira/browse/AURORA-1854). 
> The goal is to add JMH benchmarks for SlaCalculation and then other metric 
> calculators.
> 
> 
> Diffs
> -
> 
>   src/jmh/java/org/apache/aurora/benchmark/SlaAlgorithmBenchmark.java 
> PRE-CREATION 
>   src/jmh/java/org/apache/aurora/benchmark/Tasks.java 
> 3aabc5ef222a97d8ebde693c52030a66bca340d2 
>   src/main/java/org/apache/aurora/scheduler/sla/SlaAlgorithm.java 
> 5d8d5bd8f705770979f284d26d2e932aabe707e5 
> 
> Diff: https://reviews.apache.org/r/55284/diff/
> 
> 
> Testing
> ---
> 
> the content of <./aurora/dist/reports/jmh/human.txt>
> 
> ```
> # JMH 1.15 (released 102 days ago)
> # VM version: JDK 1.8.0_111, VM 25.111-b14
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
> # VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US 
> -Duser.language=en -Duser.variant
> # Warmup: 1 iterations, 10 s each
> # Measurement: 5 iterations, 5 s each
> # Timeout: 10 min per iteration
> # Threads: 1 thread, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: 
> org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
> # Parameters: (numTasks = 1000)
> 
> # Run progress: 0.00% complete, ETA 00:07:00
> # Fork: 1 of 1
> # Warmup Iteration   1: 5141.403 ops/s
> Iteration   1: 5514.591 ops/s
> Iteration   2: 5508.875 ops/s
> Iteration   3: 5594.224 ops/s
> Iteration   4: 5467.605 ops/s
> Iteration   5: 5619.229 ops/s
> 
> 
> Result "measureMTTA":
>   5540.905 ±(99.9%) 244.059 ops/s [Average]
>   (min, avg, max) = (5467.605, 5540.905, 5619.229), stdev = 63.381
>   CI (99.9%): [5296.846, 5784.963] (assumes normal distribution)
> 
> 
> # JMH 1.15 (released 102 days ago)
> # VM version: JDK 1.8.0_111, VM 25.111-b14
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
> # VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US 
> -Duser.language=en -Duser.variant
> # Warmup: 1 iterations, 10 s each
> # Measurement: 5 iterations, 5 s each
> # Timeout: 10 min per iteration
> # Threads: 1 thread, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: 
> org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
> # Parameters: (numTasks = 1)
> 
> # Run progress: 8.33% complete, ETA 00:06:34
> # Fork: 1 of 1
> # Warmup Iteration   1: 64.993 ops/s
> Iteration   1: 61.762 ops/s
> Iteration   2: 64.468 ops/s
> Iteration   3: 65.047 ops/s
> Iteration   4: 63.199 ops/s
> Iteration   5: 64.412 ops/s
> 
> 
> Result "measureMTTA":
>   63.778 ±(99.9%) 5.053 ops/s [Average]
>   (min, avg, max) = (61.762, 63.778, 65.047), stdev = 1.312
>   CI (99.9%): [58.725, 68.830] (assumes normal distribution)
> 
> 
> # JMH 1.15 (released 102 days ago)
> # VM version: JDK 1.8.0_111, VM 25.111-b14
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
> # VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US 
> -Duser.language=en -Duser.variant
> # Warmup: 1 iterations, 10 s each
> # Measurement: 5 iterations, 5 s each
> # Timeout: 10 min per iteration
> # Threads: 1 thread, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: 
> org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
> # Parameters: (numTasks = 10)
> 
> # Run progress: 16.67% complete, ETA 00:06:00
> # Fork: 1 of 1
> # Warmup Iteration   1: 0.490 ops/s
> Iteration   1: 0.556 ops/s
> Iteration   2: 0.503 ops/s
> Iteration   3: 0.502 ops/s
>

Re: Review Request 55284: Benchmarking SLA Algorithms

2017-01-10 Thread Aurora ReviewBot


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



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


:commons:generateThriftResources
:commons:processResources
:commons:classes
:commons:jar
:compileJava/home/jenkins/jenkins-slave/workspace/AuroraBot/src/main/java/org/apache/aurora/scheduler/storage/log/WriteAheadStorage.java:74:
 Note: Wrote forwarder 
org.apache.aurora.scheduler.storage.log.WriteAheadStorageForwarder
@Forward({
^
Note: Writing 
file:/home/jenkins/jenkins-slave/workspace/AuroraBot/dist/classes/main/org/apache/aurora/common/args/apt/cmdline.arg.info.txt.2
Note: Writing 
file:/home/jenkins/jenkins-slave/workspace/AuroraBot/dist/classes/main/META-INF/compiler/resource-mappings/org.apache.aurora.common.args.apt.CmdLineProcessor

:generateBuildProperties
:processResources
:classes
:jar
:startScripts
:distTar
:distZip
:assemble
:compileJmhJavaNote: 
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/jmh/java/org/apache/aurora/benchmark/fakes/FakeSchedulerDriver.java
 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:processJmhResources UP-TO-DATE
:jmhClasses
:checkstyleJmh[ant:checkstyle] [ERROR] 
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/jmh/java/org/apache/aurora/benchmark/Tasks.java:18:8:
 Unused import - java.util.Optional. [UnusedImports]
[ant:checkstyle] [ERROR] 
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/jmh/java/org/apache/aurora/benchmark/Tasks.java:107:54:
 '{' is not preceded with whitespace. [WhitespaceAround]
 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':checkstyleJmh'.
> Checkstyle rule violations were found. See the report at: 
> file:///home/jenkins/jenkins-slave/workspace/AuroraBot/dist/reports/checkstyle/jmh.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: 1 mins 8.49 secs


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

- Aurora ReviewBot


On Jan. 10, 2017, 9 a.m., Reza Motamedi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55284/
> ---
> 
> (Updated Jan. 10, 2017, 9 a.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Mehrdad Nurolahzade, and Santhosh 
> Kumar Shanmugham.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> # Adding SLA benchmarks benchmarks 
> This RB is related to 
> [AURORA-1854](https://issues.apache.org/jira/browse/AURORA-1854). 
> The goal is to add JMH benchmarks for SlaCalculation and then other metric 
> calculators.
> 
> 
> Diffs
> -
> 
>   src/jmh/java/org/apache/aurora/benchmark/SlaAlgorithmBenchmark.java 
> PRE-CREATION 
>   src/jmh/java/org/apache/aurora/benchmark/Tasks.java 
> 3aabc5ef222a97d8ebde693c52030a66bca340d2 
>   src/main/java/org/apache/aurora/scheduler/sla/SlaAlgorithm.java 
> 5d8d5bd8f705770979f284d26d2e932aabe707e5 
> 
> Diff: https://reviews.apache.org/r/55284/diff/
> 
> 
> Testing
> ---
> 
> the content of <./aurora/dist/reports/jmh/human.txt>
> 
> ```
> # JMH 1.15 (released 102 days ago)
> # VM version: JDK 1.8.0_111, VM 25.111-b14
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
> # VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US 
> -Duser.language=en -Duser.variant
> # Warmup: 1 iterations, 10 s each
> # Measurement: 5 iterations, 5 s each
> # Timeout: 10 min per iteration
> # Threads: 1 thread, will synchronize iterations
> # Benchmark mode: Throughput, ops/time
> # Benchmark: 
> org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
> # Parameters: (numTasks = 1000)
> 
> # Run progress: 0.00% complete, ETA 00:07:00
> # Fork: 1 of 1
> # Warmup Iteration   1: 5141.403 ops/s
> Iteration   1: 5514.591 ops/s
> Iteration   2: 5508.875 ops/s
> Iteration   3: 5594.224 ops/s
> Iteration   4: 5467.605 ops/s
> Iteration   5: 5619.229 ops/s
> 
> 
> Result "measureMTTA":
>   5540.905 ±(99.9%) 244.059 ops/s [Average]
>   (min, avg, max) = (5467.605, 5540.905, 5619.229), stdev = 63.381
>   CI (99.9%): [5296.846, 5784.963] (assumes normal distribution)
> 
> 
> # JMH 1.15 (released 102 days ago)
> # VM version: JDK 1.8.0_111, VM 25.111-b14
> # VM invoker: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
> # VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US 
> -Duser.language=en -Duser.variant
> # Warmup: 1 iterations, 10 s each
> # Measurement: 5 iterations, 5 s each
> # Timeout: 10 min per iteration
> # Threads: 1 thread, will synchronize iterations
> # Benchmark mode:

Re: Review Request 55284: Benchmarking SLA Algorithms

2017-01-10 Thread Reza Motamedi


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

(Updated Jan. 10, 2017, 9 a.m.)


Review request for Aurora, Joshua Cohen, Mehrdad Nurolahzade, and Santhosh 
Kumar Shanmugham.


Summary (updated)
-

Benchmarking SLA Algorithms


Repository: aurora


Description
---

# Adding SLA benchmarks benchmarks 
This RB is related to 
[AURORA-1854](https://issues.apache.org/jira/browse/AURORA-1854). 
The goal is to add JMH benchmarks for SlaCalculation and then other metric 
calculators.


Diffs
-

  src/jmh/java/org/apache/aurora/benchmark/SlaAlgorithmBenchmark.java 
PRE-CREATION 
  src/jmh/java/org/apache/aurora/benchmark/Tasks.java 
3aabc5ef222a97d8ebde693c52030a66bca340d2 
  src/main/java/org/apache/aurora/scheduler/sla/SlaAlgorithm.java 
5d8d5bd8f705770979f284d26d2e932aabe707e5 

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


Testing
---

the content of <./aurora/dist/reports/jmh/human.txt>

```
# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 1000)

# Run progress: 0.00% complete, ETA 00:07:00
# Fork: 1 of 1
# Warmup Iteration   1: 5141.403 ops/s
Iteration   1: 5514.591 ops/s
Iteration   2: 5508.875 ops/s
Iteration   3: 5594.224 ops/s
Iteration   4: 5467.605 ops/s
Iteration   5: 5619.229 ops/s


Result "measureMTTA":
  5540.905 ±(99.9%) 244.059 ops/s [Average]
  (min, avg, max) = (5467.605, 5540.905, 5619.229), stdev = 63.381
  CI (99.9%): [5296.846, 5784.963] (assumes normal distribution)


# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 1)

# Run progress: 8.33% complete, ETA 00:06:34
# Fork: 1 of 1
# Warmup Iteration   1: 64.993 ops/s
Iteration   1: 61.762 ops/s
Iteration   2: 64.468 ops/s
Iteration   3: 65.047 ops/s
Iteration   4: 63.199 ops/s
Iteration   5: 64.412 ops/s


Result "measureMTTA":
  63.778 ±(99.9%) 5.053 ops/s [Average]
  (min, avg, max) = (61.762, 63.778, 65.047), stdev = 1.312
  CI (99.9%): [58.725, 68.830] (assumes normal distribution)


# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 10)

# Run progress: 16.67% complete, ETA 00:06:00
# Fork: 1 of 1
# Warmup Iteration   1: 0.490 ops/s
Iteration   1: 0.556 ops/s
Iteration   2: 0.503 ops/s
Iteration   3: 0.502 ops/s
Iteration   4: 0.576 ops/s
Iteration   5: 0.591 ops/s


Result "measureMTTA":
  0.546 ±(99.9%) 0.159 ops/s [Average]
  (min, avg, max) = (0.502, 0.546, 0.591), stdev = 0.041
  CI (99.9%): [0.387, 0.705] (assumes normal distribution)


# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 20)

# Run progress: 25.00% complete, ETA 00:05:40
# Fork: 1 of 1
# Warmup Iteration   1: 0.099 ops/s
Iteration   1: 0.130 ops/s
Iteration   2: 0.146 ops/s
Iteration   3: 0.117 ops/s
Iteration   4: 0.145 ops/s
Iteration   5: 0.144 ops/s


Result "measureMTTA":
  0.137 ±(99.9%)

Re: Review Request 55284: Benchmarking

2017-01-10 Thread Reza Motamedi


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

(Updated Jan. 10, 2017, 9 a.m.)


Review request for Aurora, Joshua Cohen, Mehrdad Nurolahzade, and Santhosh 
Kumar Shanmugham.


Changes
---

- partially refactored Task Builder to accept a list of TaskEvents.
- updated the number of tasks to show a mathc a more reasonable load.

```
Benchmark(numTasks)   Mode  Cnt 
Score  Error  Units
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA1000  thrpt5  
5540.905 ±  244.059  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA   1  thrpt5
63.778 ±5.053  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA  10  thrpt5 
0.546 ±0.159  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA  20  thrpt5 
0.137 ±0.049  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTR1000  thrpt5  
3556.555 ± 2569.449  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTR   1  thrpt5
54.058 ±   18.486  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTR  10  thrpt5 
0.460 ±0.238  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTR  20  thrpt5 
0.127 ±0.025  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTS1000  thrpt5  
3243.565 ± 6417.109  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTS   1  thrpt5
55.796 ±   13.886  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTS  10  thrpt5 
0.528 ±0.071  ops/s
SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTS  20  thrpt5 
0.115 ±0.039  ops/s

```


Repository: aurora


Description (updated)
---

# Adding SLA benchmarks benchmarks 
This RB is related to 
[AURORA-1854](https://issues.apache.org/jira/browse/AURORA-1854). 
The goal is to add JMH benchmarks for SlaCalculation and then other metric 
calculators.


Diffs (updated)
-

  src/jmh/java/org/apache/aurora/benchmark/SlaAlgorithmBenchmark.java 
PRE-CREATION 
  src/jmh/java/org/apache/aurora/benchmark/Tasks.java 
3aabc5ef222a97d8ebde693c52030a66bca340d2 
  src/main/java/org/apache/aurora/scheduler/sla/SlaAlgorithm.java 
5d8d5bd8f705770979f284d26d2e932aabe707e5 

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


Testing (updated)
---

the content of <./aurora/dist/reports/jmh/human.txt>

```
# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 1000)

# Run progress: 0.00% complete, ETA 00:07:00
# Fork: 1 of 1
# Warmup Iteration   1: 5141.403 ops/s
Iteration   1: 5514.591 ops/s
Iteration   2: 5508.875 ops/s
Iteration   3: 5594.224 ops/s
Iteration   4: 5467.605 ops/s
Iteration   5: 5619.229 ops/s


Result "measureMTTA":
  5540.905 ±(99.9%) 244.059 ops/s [Average]
  (min, avg, max) = (5467.605, 5540.905, 5619.229), stdev = 63.381
  CI (99.9%): [5296.846, 5784.963] (assumes normal distribution)


# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: 
org.apache.aurora.benchmark.SlaAlgorithmBenchmark.MTTXBenchmark.measureMTTA
# Parameters: (numTasks = 1)

# Run progress: 8.33% complete, ETA 00:06:34
# Fork: 1 of 1
# Warmup Iteration   1: 64.993 ops/s
Iteration   1: 61.762 ops/s
Iteration   2: 64.468 ops/s
Iteration   3: 65.047 ops/s
Iteration   4: 63.199 ops/s
Iteration   5: 64.412 ops/s


Result "measureMTTA":
  63.778 ±(99.9%) 5.053 ops/s [Average]
  (min, avg, max) = (61.762, 63.778, 65.047), stdev = 1.312
  CI (99.9%): [58.725, 68.830] (assumes normal distribution)


# JMH 1.15 (released 102 days ago)
# VM version: JDK 1.8.0_111, VM 25.111-b14
# VM invoker: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre/bin/java
# VM options: -Xmx3g -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en 
-Duser.variant
# Warmup: 1 iterations, 10 s each
# Measurement: 5 iterations, 5 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize

Re: Review Request 54957: Add option to not retry api calls to the scheduler.

Re: Review Request 55237: WIP for idempotent api endpoints.

Re: Review Request 55243: AURORA-1868 Evaluate multiple preemption proposals per round

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55357: AURORA-1867 Consider reserving for multiple tasks per preemption round

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55347: Ensure destination exists when mounting files into a filesystem image.

Re: Review Request 55284: Benchmarking SLA Algorithms

Re: Review Request 55284: Benchmarking SLA Algorithms

Re: Review Request 55284: Benchmarking SLA Algorithms

Re: Review Request 55284: Benchmarking

17 matches

Site Navigation

Mail list logo

Footer information