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