> On May 30, 2018, 8:17 p.m., Benjamin Mahler wrote:
> > src/common/resources.cpp
> > Lines 866-868 (original), 875-883 (patched)
> > <https://reviews.apache.org/r/67274/diff/4/?file=2032028#file2032028line875>
> >
> >     Can we reject 0? We were previously allowing it?
> 
> Jie Yu wrote:
>     Yes, we debated that. I feel that specifing the resource to be zero is 
> not a valid use case anyway (simply not specify the resource in that case). 
> We plan to send an email to user list.
> 
> Benjamin Mahler wrote:
>     I think this breaks things like quota:
>     
>     limit: cpus:10;mem:10;gpu:0
>     vs
>     limit: cpus:10;mem:10
>     
>     These meean two different things, in the latter there is no gpu limit 
> whereas the former has a limit of 0.

I reverted the patch to revision 2 where we only rejected non-zero scalar 
resource values which rounded to zero (resulting in empty resources).

FYI, I checked the behavior for quota and see no difference before and after 
the patch in this revision; the allocator never sees `gpus:0`. AFACIT this 
cannot be modelled with the current `Resources` class which always drops empty 
resources in operations (e.g., invoked when parsing above resource string).


- Benjamin


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


On May 30, 2018, 11:50 p.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67274/
> -----------------------------------------------------------
> 
> (Updated May 30, 2018, 11:50 p.m.)
> 
> 
> Review request for mesos, Jie Yu, Joris Van Remoortere, Michael Park, and 
> Neil Conway.
> 
> 
> Bugs: MESOS-8945
>     https://issues.apache.org/jira/browse/MESOS-8945
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Internally values of scalar resources are stored in a fixed point
> representation. This can lead to (expected) precision loss.
> 
> This patch updates the resource validation ensuring that values of
> scalar resources are either zero or large enough so that they are
> still represented as non-zero values after conversion to the internal
> fixed point format. With that we can still parse resources containing
> resource values explictly set to zero to be able to distinguish empty
> and abset resources, but prevent propagation of values accidentially
> rounded to an effectively empty result.
> 
> While this patch should not change valid, intended use cases, it might
> change the behavior for erroneous, already broken framework workflows.
> 
> 
> Diffs
> -----
> 
>   src/common/resources.cpp 192d086e60b81c0ae8e26d4120beee2034f63d3e 
>   src/tests/master_tests.cpp 6efcbd12902de32428cb7f23ed0d3967a18f749d 
>   src/tests/resources_tests.cpp 1201efec3ff0abc268f896c1fe2330571390b3fd 
> 
> 
> Diff: https://reviews.apache.org/r/67274/diff/5/
> 
> 
> Testing
> -------
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Reply via email to