> On Aug. 27, 2015, 5:23 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/TierManager.java, line 63 > > <https://reviews.apache.org/r/37825/diff/1/?file=1055551#file1055551line63> > > > > Consider moving the parsing up a layer, in the module. That way we can > > report earlier if the file is malformed, and you can bind a specific type > > (without the annotation). > > > > This will also address another complaint, which is that the config file > > is being parsed every time we want to find the tier a task config belongs > > to. > > Bill Farner wrote: > > This will also address another complaint, which is that the config file > is being parsed every time we want to find the tier a task config belongs to.' > > Sorry, this was a lie. Please ignore.
Good point. This was done mainly for testability but nothing prevents testing it in the module either. > On Aug. 27, 2015, 5:23 p.m., Bill Farner wrote: > > src/test/resources/org/apache/aurora/scheduler/tiers-example.json, line 2 > > <https://reviews.apache.org/r/37825/diff/1/?file=1055553#file1055553line2> > > > > The added layer here seems slightly weird, but i can see why it's > > useful - you can add other fields to the config in the future. I don't > > necessarily expect you to change anything, but i'm curious if that was your > > intention. > > Zameer Manji wrote: > This also seems weird to me. I think a good schema for the file would be > { <tier name>: <tier properties> }. Maybe this requires a mailing list > discussion? > > Maxim Khutornenko wrote: > Bill was on target with his guess. The extra layer does not add much > overhead and at the same time does not prevent adding extra metadata in > future. This is the same logical structuring proposed in the design doc. > > Bill Farner wrote: > I'm all for discussion on the mailing list, but i think this is minutia > that is safe to define here and avoid the overhead of outreach/waiting. +1. Given that the structure has been laid down in the design doc, I'd like to proceed with this schema and reserve dev for heavier weight discussions. > On Aug. 27, 2015, 5:23 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/SchedulerModule.java, line 70 > > <https://reviews.apache.org/r/37825/diff/1/?file=1055550#file1055550line70> > > > > +@CanRead > > Kevin Sweeney wrote: > That will cause loading to fail when the argument is null. Exactly. Added a comment in the TODO to address it later. - Maxim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37825/#review96703 ----------------------------------------------------------- On Aug. 27, 2015, 1:07 a.m., Maxim Khutornenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37825/ > ----------------------------------------------------------- > > (Updated Aug. 27, 2015, 1:07 a.m.) > > > Review request for Aurora, Bill Farner and Zameer Manji. > > > Bugs: AURORA-1437 > https://issues.apache.org/jira/browse/AURORA-1437 > > > Repository: aurora > > > Description > ------- > > The external config file is optional for now as tiers are not fully defined > yet. > > > Diffs > ----- > > examples/vagrant/upstart/aurora-scheduler-kerberos.conf > 744b4a35c61e749734e222b3d4cbd296927665aa > examples/vagrant/upstart/aurora-scheduler.conf > 789a3a0315e8530880999432aa9b1e7d0f57d1ff > src/main/java/org/apache/aurora/scheduler/SchedulerModule.java > d4bc6b9bb10c982fb6a2458d7fdd12bddbe98eca > src/main/java/org/apache/aurora/scheduler/TierManager.java > 652afece17a7eb09b0ca68066707b1b8fbf024f0 > src/test/java/org/apache/aurora/scheduler/TierManagerTest.java > eb0207114e1b93968cb65832f154a9cd3bc3232e > src/test/resources/org/apache/aurora/scheduler/tiers-example.json > PRE-CREATION > > Diff: https://reviews.apache.org/r/37825/diff/ > > > Testing > ------- > > ./gradlew -Pq build > ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh > > > Thanks, > > Maxim Khutornenko > >
