mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Meng Zhu <m...@mesosphere.io>
Subject Re: Review Request 70132: Do not implicitly refuse speculatively converted resources.
Date Wed, 06 Mar 2019 02:29:09 GMT

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




src/master/master.cpp
Lines 5918-5920 (patched)
<https://reviews.apache.org/r/70132/#comment299393>

    Not sure what value the comment has. Maybe you want to express its dependency on certain
`Resources` subtraction semantics such as dropping negatives? Is so, either spit that out
or I think you can just remove the comment.



src/master/master.cpp
Lines 5920 (patched)
<https://reviews.apache.org/r/70132/#comment299394>

    how about just name it `updatedResources` which is easier to grasp. In this particular
context, it's just the diff after the operation update (as opppose to "unused" below) whether
it is speculative or not does not matter.



src/master/master.cpp
Lines 5921-5928 (original), 5928-5937 (patched)
<https://reviews.apache.org/r/70132/#comment299395>

    hmm, I wonder if it is better to also not implicitly filter `unusedResources` if `speculativeResources`
is not empty.
    
    If a framework wants to consume the updated resources e.g. volume, it probably also wants
other resources such as cpu/mem (unless it can consume disk only resource). In that case,
the above code would not improve the situation because the framework still needs to wait for
the filtered cpu/mem. Also I am a little uncomfortable that, we now have *two* recoverResources
calls which could increase agent resource fragmentation (if an offer is sent out in between).
    
    what do you think?


- Meng Zhu


On March 5, 2019, 4:53 p.m., Chun-Hung Hsiao wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> -----------------------------------------------------------
> 
> (Updated March 5, 2019, 4:53 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
>     https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly refused. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be refused.
> 
> 
> Diffs
> -----
> 
>   docs/scheduler-http-api.md 8384336bbecf2ca38a3cd203f9db28d931812d65 
>   src/master/master.cpp 015da54583448a8d102d8e401e48bd228baf6dd6 
>   src/tests/slave_tests.cpp 22a0295086ae4f4ec26df00a0e077eecfa27f1fb 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/1/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message