You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@aurora.apache.org by Kevin Sweeney <ke...@apache.org> on 2015/03/02 20:14:16 UTC
Re: Review Request 31525: Improving NearestFit reporting accuracy.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31525/#review74793
-----------------------------------------------------------
src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilter.java
<https://reviews.apache.org/r/31525/#comment121550>
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.
- Kevin Sweeney
On Feb. 27, 2015, 1: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, 1: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
>
>
Re: Review Request 31525: Improving NearestFit reporting accuracy.
Posted by Maxim Khutornenko <ma...@apache.org>.
> 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
>
>