----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70892/#review216264 -----------------------------------------------------------
src/slave/http.hpp Lines 84 (patched) <https://reviews.apache.org/r/70892/#comment303393> s/containerizer_debug/containerizerDebug/ src/slave/http.hpp Lines 130 (patched) <https://reviews.apache.org/r/70892/#comment303395> s/_containerizer_debug/_containerizerDebug/ src/slave/http.cpp Lines 2350-2352 (patched) <https://reviews.apache.org/r/70892/#comment303394> Can we merge them into a single paragraph? src/slave/http.cpp Lines 2428-2429 (patched) <https://reviews.apache.org/r/70892/#comment303397> Why do we put an array into an array (`futures`)? I think we should put `JSON::Object` into the `futures` array, and in the `JSON::Object` there should be two fields: name and args. src/slave/http.cpp Lines 2431 (patched) <https://reviews.apache.org/r/70892/#comment303396> If this endpoint will only return pending operations, do we really need the `pending` here? I think we can just return a `JSON::ARRAY` instead of `JSON::OBJECT` and each element in the array is a pending operations. Or we may consider to add other info (other than pending operations) into this endpoint? src/slave/slave.cpp Lines 837 (patched) <https://reviews.apache.org/r/70892/#comment303399> Do we plan to return pending operations for other components rather than just containerizer in future? If yes, then I think we'd better give it a generic name (like `/debug`) and return component name (currently it is just `containerizer`) along with operation name and args in the response. - Qian Zhang On June 19, 2019, 10:49 p.m., Andrei Budnik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/70892/ > ----------------------------------------------------------- > > (Updated June 19, 2019, 10:49 p.m.) > > > Review request for mesos, Gilbert Song, James Peach, and Qian Zhang. > > > Bugs: MESOS-9829 > https://issues.apache.org/jira/browse/MESOS-9829 > > > Repository: mesos > > > Description > ------- > > This patch introduces an agent's `/containerizer/debug` endpoint, > which exposes the debug info related to Mesos containerizer. > Currently, this endpoint returns a list of pending futures related to > isolators or containerizer launcher. This endpoint is experimental, > and the format of its output may change over time. > > > Diffs > ----- > > src/slave/http.hpp b8c83f1db95c2175bb94f6cd76cc2c58aa118c4e > src/slave/http.cpp 69e6d74e8b113cc6c937f47df8984ff9a63e5bb4 > src/slave/slave.cpp 30039b0857a4d85b4b96fa95d7f8724d57cdec6e > > > Diff: https://reviews.apache.org/r/70892/diff/1/ > > > Testing > ------- > > Manual testing. > 1. Add `::sleep(5)` to the beginning of the > `LinuxSeccompIsolatorProcess::prepare` method. > 2. Rebuild Mesos and then spin up a local Mesos cluster. > 3. Run simple task, e.g.: > ``` > ./src/mesos-execute --master="`hostname`:5050" --name="test" > --containerizer=mesos --command="sleep 1" > ``` > 4. In the parallel terminal session: > ``` > curl `hostname`:5051/containerizer/debug > # will return: > {"pending":[["linux/seccomp::prepare",{"containerId":"<container id>"}]]} > ``` > 5. After 5 seconds this endpoint returns an empty list of pending futures: > `{"pending":[]}` > > Unit tests: TBD in the following patches. > > > Thanks, > > Andrei Budnik > >
