> On Jan. 8, 2020, 5:43 a.m., Greg Mann wrote: > > src/slave/slave.cpp > > Lines 3116 (patched) > > <https://reviews.apache.org/r/71858/diff/4/?file=2191535#file2191535line3116> > > > > Are we using `-1` for this? I thought the plan was to use `INFINITY`?
Yeah, that's why I marked this patch as WIP :-) Once https://issues.apache.org/jira/browse/MESOS-10064 is resolved, I will update this patch accordingly. > On Jan. 8, 2020, 5:43 a.m., Greg Mann wrote: > > src/slave/slave.cpp > > Lines 3135-3136 (patched) > > <https://reviews.apache.org/r/71858/diff/4/?file=2191535#file2191535line3135> > > > > Could you be consistent with the naming here, either do > > "executorCpuLimit/executorCpuRequest" or "cpuLimit/cpuRequest"? I think here `executorCpuLimit` is indeed the cpu limit of executor, but `cpuRequest` is actually not the cpu request of executor, instead it is the cpu request of all tasks which do not have cpu limit set. So that's why I named them like this. > On Jan. 8, 2020, 5:43 a.m., Greg Mann wrote: > > src/slave/slave.cpp > > Lines 3137 (patched) > > <https://reviews.apache.org/r/71858/diff/4/?file=2191535#file2191535line3137> > > > > Our style guide prefers trailing underscores in cases like this, could > > you use `task_` instead of `_task`? I agree with you. But when you search `foreach (const TaskInfo& _task, tasks) {` in this `slave.cpp` file, you will find a lot (19 occurrences), so I'd like to keep it for now. Maybe we could post a separate patch later to refactor all of them in this file. > On Jan. 8, 2020, 5:43 a.m., Greg Mann wrote: > > src/slave/slave.cpp > > Lines 3140-3201 (patched) > > <https://reviews.apache.org/r/71858/diff/4/?file=2191535#file2191535line3140> > > > > I think maybe this logic could be easier to read if we do something > > like: > > > > ``` > > auto limitsAreSet = [](const vector<TaskInfo>& tasks) { > > foreach (const TaskInfo& task, tasks) { > > if (!task.limits().empty()) { > > return true; > > } > > } > > > > return false; > > }; > > > > Option<Map<string, Value::Scalar>> executorLimits; > > if (limitsAreSet(tasks)) { > > executorLimits = Map<string, Value::Scalar>(); > > foreach (const TaskInfo& task, tasks) { > > // Add up task limits/requests here. > > } > > } > > ``` > > > > What do you think? I am a bit confused how it will simplify the logic here, like: how will you do the `Add up task limits/requests here`? I guess you still need the code from L3140 to L3201, right? > On Jan. 8, 2020, 5:43 a.m., Greg Mann wrote: > > src/slave/slave.cpp > > Lines 3623 (patched) > > <https://reviews.apache.org/r/71858/diff/4/?file=2191535#file2191535line3628> > > > > Should this be an `Option`? So that we can only set > > `containerConfig.limits` when limits have actually been set? I added a check `if (!executorLimits.empty()) {` before setting `containerConfig.limit`, HDYT? - Qian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/71858/#review219154 ----------------------------------------------------------- On Jan. 8, 2020, 10:08 a.m., Qian Zhang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/71858/ > ----------------------------------------------------------- > > (Updated Jan. 8, 2020, 10:08 a.m.) > > > Review request for mesos, Andrei Budnik and Greg Mann. > > > Bugs: MESOS-10046 > https://issues.apache.org/jira/browse/MESOS-10046 > > > Repository: mesos > > > Description > ------- > > WIP: Set resource limits when launching executor container. > > > Diffs > ----- > > src/slave/slave.hpp 77b5bc0082c6bb73fbd48a2ebe812629921645cb > src/slave/slave.cpp 3839a120446339fea8aa857f431a2dba28ed4002 > > > Diff: https://reviews.apache.org/r/71858/diff/5/ > > > Testing > ------- > > > Thanks, > > Qian Zhang > >
