> On Sept. 12, 2016, 7:31 p.m., Maxim Khutornenko wrote:
> > src/main/java/org/apache/aurora/scheduler/resources/ResourceSettings.java, 
> > lines 22-33
> > <https://reviews.apache.org/r/51807/diff/1/?file=1496737#file1496737line22>
> >
> >     This is somewhat non-standard way to define cmd flags. We tend to 
> > declare them in modules and use 'setting' classes to act as pure wrappers. 
> > Perhaps it's time to introduce a `ResourceModule` class (if only to bind 
> > the `ResourceSettings` instance for now)?
> 
> Stephan Erb wrote:
>     I believe there would be no way to inject the settings into the 
> `ResourceType` enum at compile time with guice. That's why I've adopted this 
> approach here.  Happy to give it a try if you have some pointers for me how 
> to make it work.

Oh, that's right. I forgot java enums are extremely picky when it comes to 
field injections. Ignore this comment. Perhaps having an extra note in this 
class javadoc will help avoiding this type of questions in the future.


> On Sept. 12, 2016, 7:31 p.m., Maxim Khutornenko wrote:
> > src/main/java/org/apache/aurora/scheduler/resources/ResourceType.java, line 
> > 75
> > <https://reviews.apache.org/r/51807/diff/1/?file=1496738#file1496738line75>
> >
> >     Would be great to have a e2e test when this functionality is available 
> > in Mesos. Perhaps drop a TODO here?
> 
> Stephan Erb wrote:
>     Acutally, it would work in Mesos out of the box even today. All we have 
> to do is adapt our Mesos config to also pass along memory resources 
> https://github.com/apache/aurora/blob/master/examples/vagrant/mesos_config/etc_mesos-slave/modules#L8.
>     
>     I didn't do it because I felt like it wouldn't add any additional test 
> coverage, now that the entire resource handling within Aurora is generic.
> 
> Stephan Erb wrote:
>     Additional info: We already have an e2e test using revocable CPU 
> resources.

It's true that things should now "just work". Reality proves that's not always 
the case, so any test coverage helping to validate we can actually run tasks 
against offers with more than one revocable resource would be welcome. Does not 
have to be in this RB though.


- Maxim


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


On Sept. 12, 2016, 1:38 p.m., Stephan Erb wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51807/
> -----------------------------------------------------------
> 
> (Updated Sept. 12, 2016, 1:38 p.m.)
> 
> 
> Review request for Aurora and Maxim Khutornenko.
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> We plan to open source a very simple Mesos ResourceEstimator and 
> QosController that supports RAM and CPU oversubscription (ETA ~2 weeks). We 
> have been using it internally with a patched Aurora version where the 
> hardcoded `isMesosRevocable` flag of RAM has been set to `true`. This patch 
> makes this behaviour configurable.
> 
> 
> Diffs
> -----
> 
>   RELEASE-NOTES.md bbf7198dc7ce53bb02a1bc59f75a661e23472913 
>   docs/features/resource-isolation.md 
> 01c5b407a4964e89741d0f6c72d04ab5dc4c2f87 
>   docs/operations/configuration.md 90dde574ce517355d2d6045a5ab036c1a3838882 
>   docs/reference/scheduler-configuration.md 
> 87d2cded0780ffa34884b52cc049c6a0ad808f0a 
>   src/main/java/org/apache/aurora/scheduler/resources/ResourceSettings.java 
> PRE-CREATION 
>   src/main/java/org/apache/aurora/scheduler/resources/ResourceType.java 
> 4c102a3d4c4bdd27a1d0536b689acd6257e77788 
> 
> Diff: https://reviews.apache.org/r/51807/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew -Pq build
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Reply via email to