You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Alexander Rukletsov <ru...@gmail.com> on 2017/02/02 09:57:03 UTC
Review Request 56210: Reused previous task status to generate a new
one in command executor.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new task status update is generated in the executor, we have
to make sure specific data is duplicated from the previous update
to, e.g., avoid shadowing of those data during reconciliation. For
instance, consider a check status being sent; in this status update
we must include the latest known health information.
Diffs
-----
src/launcher/executor.cpp 0c770bb18ae8bd8df85589b5262f457ab50574a9
Diff: https://reviews.apache.org/r/56210/diff/
Testing
-------
See https://reviews.apache.org/r/56218/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Vinod Kone <vi...@gmail.com>.
> On Feb. 8, 2017, 1:08 a.m., Vinod Kone wrote:
> > src/launcher/executor.cpp, line 720
> > <https://reviews.apache.org/r/56210/diff/1/?file=1622060#file1622060line720>
> >
> > looks like this review doesn't use `reason` argument, so I wouldn't add it in this review. lets add it in the review that needs it.
>
> Alexander Rukletsov wrote:
> A'd rather keep it here, because I would like API to look consistent. What are general things people should probably set if they generate a status update? State, reason, message. They are not specific to any particular update or feature (e.g., check update).
"I would like API to look consistent" : Consistent with what? It's not clear to me why someone creating a status update only cares about state/reason/message. That seems very specific to this use case. If I have the executor sending a TASK_STARTING update for example, I cannot use either of these helpers as they exist in this review.
> On Feb. 8, 2017, 1:08 a.m., Vinod Kone wrote:
> > src/launcher/executor.cpp, lines 714-753
> > <https://reviews.apache.org/r/56210/diff/1/?file=1622060#file1622060line714>
> >
> > I think these helpers are bit confusing. For example, it's not clear to me when I should use `update()` vs `bootstrappedUpdate()` when I write new code in the future that generates a status update (say TASK_STARTING). The comment on top of `update()` seems too specific to health checks for the generic function names that you picked here.
> >
> > Is `update` supposed to be used when `TaskState` changes whereas the `bootstrappedUpdate` should be used when it doesn't? I hope not because even if TaskState changes you would want to preserve health and check status. Right now it kinda works because TASK_RUNNING is the only state that can have different health / check statuses, whereas TASK_KILLING or TASK_FINISHED or TASK_FINISHED don't need that info.
> >
> > Alternatively, can we just merge these 2 into one helper that takes a bunch of optional fields that can overwrite fields in `lastTaskStatus`? Would that be more intuitive?
>
> Alexander Rukletsov wrote:
> I think there is value in having two helpers: one for creating an update from scratch and one for creating an update from a previous one. We can merge them, but I'd prefer having them separate because they clear express the intent.
>
> Now, it's hard to say when to use one and when the other. It's up to the framework's writer whether they want to preserve certain data or not. I doubt we should tell people to use the bootstrapped version by default, since it implies sending more data over the network. I think currently we should leave this decision to an executor writer and come up with a guideline in the nearest future. I have a related RR here: https://reviews.apache.org/r/56017/ and will plan to start a thread on the devlist about it.
>
> What we should do though, is to explain what these two helpers do so that executor authors can use them wisely. Does this sound like a good plan to you?
I agree that having 2 different helpers might be useful, but the current signatures (names and args) of these helpers are not intuitive to me. If you want to tackle the problem of right helper function in r/56017, I would rather you avoid creating this helper in this review and just inline the code with a TODO. I really want to avoid introducing non-intuitive helper functions.
- Vinod
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review164584
-----------------------------------------------------------
On Feb. 9, 2017, 12:56 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 9, 2017, 12:56 p.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new task status update is generated in the executor, we have
> to make sure specific data is duplicated from the previous update
> to, e.g., avoid shadowing of those data during reconciliation. For
> instance, consider a check status being sent; in this status update
> we must include the latest known health information.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
>
> Diff: https://reviews.apache.org/r/56210/diff/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56218/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
> On Feb. 8, 2017, 1:08 a.m., Vinod Kone wrote:
> > src/launcher/executor.cpp, line 720
> > <https://reviews.apache.org/r/56210/diff/1/?file=1622060#file1622060line720>
> >
> > looks like this review doesn't use `reason` argument, so I wouldn't add it in this review. lets add it in the review that needs it.
A'd rather keep it here, because I would like API to look consistent. What are general things people should probably set if they generate a status update? State, reason, message. They are not specific to any particular update or feature (e.g., check update).
> On Feb. 8, 2017, 1:08 a.m., Vinod Kone wrote:
> > src/launcher/executor.cpp, line 752
> > <https://reviews.apache.org/r/56210/diff/1/?file=1622060#file1622060line752>
> >
> > ditto. no `reason` argument in this review.
See above.
- Alexander
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review164584
-----------------------------------------------------------
On Feb. 8, 2017, 4:56 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 8, 2017, 4:56 p.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new task status update is generated in the executor, we have
> to make sure specific data is duplicated from the previous update
> to, e.g., avoid shadowing of those data during reconciliation. For
> instance, consider a check status being sent; in this status update
> we must include the latest known health information.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
>
> Diff: https://reviews.apache.org/r/56210/diff/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56218/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
> On Feb. 8, 2017, 1:08 a.m., Vinod Kone wrote:
> > src/launcher/executor.cpp, lines 714-753
> > <https://reviews.apache.org/r/56210/diff/1/?file=1622060#file1622060line714>
> >
> > I think these helpers are bit confusing. For example, it's not clear to me when I should use `update()` vs `bootstrappedUpdate()` when I write new code in the future that generates a status update (say TASK_STARTING). The comment on top of `update()` seems too specific to health checks for the generic function names that you picked here.
> >
> > Is `update` supposed to be used when `TaskState` changes whereas the `bootstrappedUpdate` should be used when it doesn't? I hope not because even if TaskState changes you would want to preserve health and check status. Right now it kinda works because TASK_RUNNING is the only state that can have different health / check statuses, whereas TASK_KILLING or TASK_FINISHED or TASK_FINISHED don't need that info.
> >
> > Alternatively, can we just merge these 2 into one helper that takes a bunch of optional fields that can overwrite fields in `lastTaskStatus`? Would that be more intuitive?
I think there is value in having two helpers: one for creating an update from scratch and one for creating an update from a previous one. We can merge them, but I'd prefer having them separate because they clear express the intent.
Now, it's hard to say when to use one and when the other. It's up to the framework's writer whether they want to preserve certain data or not. I doubt we should tell people to use the bootstrapped version by default, since it implies sending more data over the network. I think currently we should leave this decision to an executor writer and come up with a guideline in the nearest future. I have a related RR here: https://reviews.apache.org/r/56017/ and will plan to start a thread on the devlist about it.
What we should do though, is to explain what these two helpers do so that executor authors can use them wisely. Does this sound like a good plan to you?
- Alexander
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review164584
-----------------------------------------------------------
On Feb. 8, 2017, 4:56 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 8, 2017, 4:56 p.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new task status update is generated in the executor, we have
> to make sure specific data is duplicated from the previous update
> to, e.g., avoid shadowing of those data during reconciliation. For
> instance, consider a check status being sent; in this status update
> we must include the latest known health information.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
>
> Diff: https://reviews.apache.org/r/56210/diff/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56218/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Vinod Kone <vi...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review164584
-----------------------------------------------------------
src/launcher/executor.cpp (lines 714 - 753)
<https://reviews.apache.org/r/56210/#comment236370>
I think these helpers are bit confusing. For example, it's not clear to me when I should use `update()` vs `bootstrappedUpdate()` when I write new code in the future that generates a status update (say TASK_STARTING). The comment on top of `update()` seems too specific to health checks for the generic function names that you picked here.
Is `update` supposed to be used when `TaskState` changes whereas the `bootstrappedUpdate` should be used when it doesn't? I hope not because even if TaskState changes you would want to preserve health and check status. Right now it kinda works because TASK_RUNNING is the only state that can have different health / check statuses, whereas TASK_KILLING or TASK_FINISHED or TASK_FINISHED don't need that info.
Alternatively, can we just merge these 2 into one helper that takes a bunch of optional fields that can overwrite fields in `lastTaskStatus`? Would that be more intuitive?
src/launcher/executor.cpp (line 720)
<https://reviews.apache.org/r/56210/#comment236351>
looks like this review doesn't use `reason` argument, so I wouldn't add it in this review. lets add it in the review that needs it.
src/launcher/executor.cpp (line 752)
<https://reviews.apache.org/r/56210/#comment236352>
ditto. no `reason` argument in this review.
src/launcher/executor.cpp (line 775)
<https://reviews.apache.org/r/56210/#comment236350>
s/sendTaskStatusUpdate/forward/
- Vinod Kone
On Feb. 2, 2017, 9:57 a.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 2, 2017, 9:57 a.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new task status update is generated in the executor, we have
> to make sure specific data is duplicated from the previous update
> to, e.g., avoid shadowing of those data during reconciliation. For
> instance, consider a check status being sent; in this status update
> we must include the latest known health information.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp 0c770bb18ae8bd8df85589b5262f457ab50574a9
>
> Diff: https://reviews.apache.org/r/56210/diff/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56218/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Gastón Kleiman <ga...@mesosphere.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review165539
-----------------------------------------------------------
src/launcher/executor.cpp (line 828)
<https://reviews.apache.org/r/56210/#comment237405>
s/Rewrite/Overwrite/ or Update?
- Gast�n Kleiman
On Feb. 9, 2017, 12:56 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 9, 2017, 12:56 p.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new task status update is generated in the executor, we have
> to make sure specific data is duplicated from the previous update
> to, e.g., avoid shadowing of those data during reconciliation. For
> instance, consider a check status being sent; in this status update
> we must include the latest known health information.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
>
> Diff: https://reviews.apache.org/r/56210/diff/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56218/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status for health
updates in command executor.
Posted by Vinod Kone <vi...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/#review167770
-----------------------------------------------------------
Fix it, then Ship it!
Looks much cleaner. Thanks for the cleanup!
src/launcher/executor.cpp
Line 744 (original), 769 (patched)
<https://reviews.apache.org/r/56210/#comment239735>
s/if you want status update to be create/ to create a status update/
- Vinod Kone
On Feb. 28, 2017, 3:52 p.m., Alexander Rukletsov wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56210/
> -----------------------------------------------------------
>
> (Updated Feb. 28, 2017, 3:52 p.m.)
>
>
> Review request for mesos, Gast�n Kleiman and Vinod Kone.
>
>
> Bugs: MESOS-6906
> https://issues.apache.org/jira/browse/MESOS-6906
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When a new health task status update is generated in the executor, we
> have to make sure specific data is duplicated from the previous one to
> avoid shadowing of those data during reconciliation.
>
>
> Diffs
> -----
>
> src/launcher/executor.cpp adcc50fb7df91b9f8dff0f583b61e0efcd6da378
>
>
> Diff: https://reviews.apache.org/r/56210/diff/5/
>
>
> Testing
> -------
>
> See https://reviews.apache.org/r/56213/
>
>
> Thanks,
>
> Alexander Rukletsov
>
>
Re: Review Request 56210: Reused previous task status for health
updates in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated March 15, 2017, 12:47 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Changes
-------
Rebased. NNTR.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new health task status update is generated in the executor, we
have to make sure specific data is duplicated from the previous one to
avoid shadowing of those data during reconciliation.
Diffs (updated)
-----
src/launcher/executor.cpp adcc50fb7df91b9f8dff0f583b61e0efcd6da378
Diff: https://reviews.apache.org/r/56210/diff/8/
Changes: https://reviews.apache.org/r/56210/diff/7-8/
Testing
-------
See https://reviews.apache.org/r/56213/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status for health
updates in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated March 14, 2017, 2:07 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new health task status update is generated in the executor, we
have to make sure specific data is duplicated from the previous one to
avoid shadowing of those data during reconciliation.
Diffs (updated)
-----
src/launcher/executor.cpp adcc50fb7df91b9f8dff0f583b61e0efcd6da378
Diff: https://reviews.apache.org/r/56210/diff/7/
Changes: https://reviews.apache.org/r/56210/diff/6-7/
Testing
-------
See https://reviews.apache.org/r/56213/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status for health
updates in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated March 7, 2017, 8:39 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new health task status update is generated in the executor, we
have to make sure specific data is duplicated from the previous one to
avoid shadowing of those data during reconciliation.
Diffs (updated)
-----
src/launcher/executor.cpp adcc50fb7df91b9f8dff0f583b61e0efcd6da378
Diff: https://reviews.apache.org/r/56210/diff/6/
Changes: https://reviews.apache.org/r/56210/diff/5-6/
Testing
-------
See https://reviews.apache.org/r/56213/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status for health
updates in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated Feb. 28, 2017, 3:52 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Summary (updated)
-----------------
Reused previous task status for health updates in command executor.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description (updated)
-------
When a new health task status update is generated in the executor, we
have to make sure specific data is duplicated from the previous one to
avoid shadowing of those data during reconciliation.
Diffs (updated)
-----
src/launcher/executor.cpp adcc50fb7df91b9f8dff0f583b61e0efcd6da378
Diff: https://reviews.apache.org/r/56210/diff/
Testing (updated)
-------
See https://reviews.apache.org/r/56213/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated Feb. 28, 2017, 2:01 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new task status update is generated in the executor, we have
to make sure specific data is duplicated from the previous update
to, e.g., avoid shadowing of those data during reconciliation. For
instance, consider a check status being sent; in this status update
we must include the latest known health information.
Diffs
-----
src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
Diff: https://reviews.apache.org/r/56210/diff/
Testing
-------
See https://reviews.apache.org/r/56218/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated Feb. 9, 2017, 12:56 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new task status update is generated in the executor, we have
to make sure specific data is duplicated from the previous update
to, e.g., avoid shadowing of those data during reconciliation. For
instance, consider a check status being sent; in this status update
we must include the latest known health information.
Diffs (updated)
-----
src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
Diff: https://reviews.apache.org/r/56210/diff/
Testing
-------
See https://reviews.apache.org/r/56218/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated Feb. 8, 2017, 4:56 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new task status update is generated in the executor, we have
to make sure specific data is duplicated from the previous update
to, e.g., avoid shadowing of those data during reconciliation. For
instance, consider a check status being sent; in this status update
we must include the latest known health information.
Diffs (updated)
-----
src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
Diff: https://reviews.apache.org/r/56210/diff/
Testing
-------
See https://reviews.apache.org/r/56218/
Thanks,
Alexander Rukletsov
Re: Review Request 56210: Reused previous task status to generate a
new one in command executor.
Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56210/
-----------------------------------------------------------
(Updated Feb. 8, 2017, 3:16 p.m.)
Review request for mesos, Gast�n Kleiman and Vinod Kone.
Bugs: MESOS-6906
https://issues.apache.org/jira/browse/MESOS-6906
Repository: mesos
Description
-------
When a new task status update is generated in the executor, we have
to make sure specific data is duplicated from the previous update
to, e.g., avoid shadowing of those data during reconciliation. For
instance, consider a check status being sent; in this status update
we must include the latest known health information.
Diffs (updated)
-----
src/launcher/executor.cpp d9417ce1d5b108f5292a66010eab80f11552a969
Diff: https://reviews.apache.org/r/56210/diff/
Testing
-------
See https://reviews.apache.org/r/56218/
Thanks,
Alexander Rukletsov