> On April 23, 2015, 4:15 p.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, line 108
> > <https://reviews.apache.org/r/29748/diff/11/?file=920958#file920958line108>
> >
> >     How about we use a single resource string for clarity? Here we start a 
> > slave with `"cpus:1;mem:512;disk:0;ports:[]"` resources, while expect 
> > `"cpus:1;mem:512"` in the offer.
> 
> Michael Park wrote:
>     The slave resources are specified as `cpus:1;mem:512;disk:0;ports:[]` 
> because we use `Containerizer::resources` to parse the string which tries to 
> prove the OS for a value if unspecified. In these test cases we try to 
> reserve all of the resources, but we'll also have tests that don't reserve 
> all of the resources. I thought it would be good to keep the slave resources 
> and the reserved resources separated. What do you think?
> 
> Michael Park wrote:
>     `s/prove/probe`

I see, that makes sense! Mind transforming and leaving this as a short note in 
the code and then fix the issue?


- Alexander


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


On May 2, 2015, 4:14 a.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29748/
> -----------------------------------------------------------
> 
> (Updated May 2, 2015, 4:14 a.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2489
>     https://issues.apache.org/jira/browse/MESOS-2489
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am 93c7c8a807a33ab639be6289535bbd32022aa85b 
>   src/tests/reservation_tests.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/29748/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Reply via email to