> On March 2, 2015, 7:14 p.m., Kevin Sweeney wrote:
> > src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java, 
> > line 64
> > <https://reviews.apache.org/r/31525/diff/2/?file=880724#file880724line64>
> >
> >     I don't think the Math.pow approach is necessary - why not make score 
> > an EnumMap<VetoType, Integer> (or just an EnumSet<VetoType>). A veto 
> > increments the counter in the bucket for its type (or sets the bit for it). 
> > Still very efficient and more type-safe.

Not sure I understand the proposal. The score buckets, as currently defined, 
flatten out the VetoType hierarchy via non-intersecting int ranges. This 
abstracts out the internal VetoType relationship and simplifies the consuming 
side (NearestFit). The sum of all previous level veto scores should never 
exceed the next level score. I don't see how we can get by with 
EnumSet<VetoType> here without making NearestFit aware of VetoType hierarchy.


- Maxim


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


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