aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Khutornenko" <ma...@apache.org>
Subject Re: Review Request 31525: Improving NearestFit reporting accuracy.
Date Mon, 02 Mar 2015 20:54:37 GMT


> On March 2, 2015, 7:40 p.m., Bill Farner wrote:
> > Can you elaborate on how this change would have addressed this scenario described
in AURORA-1148?  Seems like the confusion of only seeing 'Insufficient RAM' is not resolved
by this change alone.

Correct, it's an incremental quality improvement rather than a comprehensive fix (which I
am not even sure is possible given our current NearestFit approach). The idea is to NOT emit
lower score (aka "better fit") vetoes until the higher score vetoes are dismissed. Here is
the most likely execution sequence in AURORA-1148 case:
1. non-decicated hosts are filtered out (veto reason: dedicated constraint mismatch)
2. dedicated hosts are evaluated wrt diversity constraints (veto reason: host limit constraint
mismatch)
3. dedicated host resources are evaluated (veto reason: insufficient RAM/CPU/DISK)

Given that every VetoType triggered short-circuits further veto analysis, users would *more*
likely see a host limit constraint. 

What this change does not solve is that in case there are some offers satisfying diversity
analysis they would "pollute" veto reason with "Insufficient resource" veto thus humpering
investigation. Given our current 10 minute veto reason expiration and default offer hold time
(5 minutes), users would likely see pending reason occasionally flipping from "host limit
mismatch" to "insufficient resource".


- Maxim


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


On Feb. 27, 2015, 9:05 p.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31525/
> -----------------------------------------------------------
> 
> (Updated Feb. 27, 2015, 9:05 p.m.)
> 
> 
> Review request for Aurora, Kevin Sweeney and Bill Farner.
> 
> 
> Bugs: AURORA-1148
>     https://issues.apache.org/jira/browse/AURORA-1148
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Instead of relying on a fixed MAX_SCORE, vetoes are now graded by their relative weight
(severity) with a dedicated constraint mismatch ranked higest and an insufficient resource
mismatch - lowest. Together with "break early" rule in SchedulingFilter, this ensures "heavier"
vetoes are given proper attention in the NearestFit. This simplifies `NearestFit` logic while
also improving pending reason reporting accuracy and scheduling performance.
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java 3313bd2f9ed5a88375d88715dea5da1e9ad8b963

>   src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java a020ce50d578fba7f32b370f448a49eb1c284147

>   src/main/java/org/apache/aurora/scheduler/metadata/NearestFit.java c3097e49c0f6588ea765aa4fab69dd35e3d90e8b

>   src/test/java/org/apache/aurora/scheduler/filter/SchedulingFilterImplTest.java b00668423a53a8cf6f4da3456bce3354f1fd2424

>   src/test/java/org/apache/aurora/scheduler/metadata/NearestFitTest.java 78a236c0f9074692b67ce18e6e03f18fe4529e02

> 
> Diff: https://reviews.apache.org/r/31525/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>


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