> 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
> 
>

Reply via email to