aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aurora ReviewBot <wfar...@apache.org>
Subject Re: Review Request 46603: Introduce command line option to control the offer filter duration
Date Wed, 27 Apr 2016 22:12:50 GMT

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


Ship it!




Master (7e30ebe) 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 April 27, 2016, 10:12 p.m., Stephan Erb wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46603/
> -----------------------------------------------------------
> 
> (Updated April 27, 2016, 10:12 p.m.)
> 
> 
> Review request for Aurora, Maxim Khutornenko and Bill Farner.
> 
> 
> Bugs: AURORA-1658
>     https://issues.apache.org/jira/browse/AURORA-1658
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Aurora is declining Mesos offers implicitly when launching a task and explicitly when
compacting multiple offers of a slave into a single one.
> The filter duration instructs Mesos to return the declined resources to us only after
a timeout of X seconds, even if there is no other framework that wants them. If no filter
is supplied, the hardcoded default of 5 seconds would be used.
> 
> By making this value configurable, Aurora can be tuned for either single or multi-framework
deployment.
> 
> 
> Diffs
> -----
> 
>   RELEASE-NOTES.md 4b810f2d808cbf0d91c753147d98d1e389106d22 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 1d725c03d16116257e1c4242ebf60f5931d4600f

>   src/jmh/java/org/apache/aurora/benchmark/fakes/FakeDriver.java d1bb8f29c9bed42c27624204b9d34ab1893468f7

>   src/main/java/org/apache/aurora/scheduler/mesos/Driver.java 013c50cf70fe45fc2a74c1ea5dccccfaba14225c

>   src/main/java/org/apache/aurora/scheduler/mesos/SchedulerDriverService.java 7ff3e3e5dc70187066b914f7feb65d99f2145303

>   src/main/java/org/apache/aurora/scheduler/offers/OfferManager.java 452451f239a964c1b55ede3d6fbde0bd805e4b00

>   src/main/java/org/apache/aurora/scheduler/offers/OfferSettings.java PRE-CREATION 
>   src/main/java/org/apache/aurora/scheduler/offers/OffersModule.java 90f8abf830478ad48f9a8a62c1c42423ab0f8d57

>   src/main/java/org/apache/aurora/scheduler/offers/RandomJitterReturnDelay.java a52fd4e8cd5c32d9560d4d72958a54bef820d81c

>   src/test/java/org/apache/aurora/scheduler/offers/OfferManagerImplTest.java 76da6d80d91221336e50d596cc2f49e890451fd1

> 
> Diff: https://reviews.apache.org/r/46603/diff/
> 
> 
> Testing
> -------
> 
> * ./gradlew -Pq build 
> * ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
>  
> I have also conducted an (unscientific) benchmark in Vagrant and started a job with 5
instances and recorded the time from `PENDING` to `RUNNING` for the slowest ones:
> 
> * 7s startup time for a filter duration of 0 seconds
> * 29s startup time for the hardcoded former default of 5 seconds
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message