By "critical path" you mean the path during action invocation?
The current PR only introduces latency on that path for the case of a Paused
container changing to Running state (once per transition from Paused ->
Running).
In case it isn't clear, this change does not affect any retry (or lack of
retry) behavior.
Thanks
Tyson
On 10/29/19, 9:38 AM, "Rodric Rabbah" <rod...@gmail.com> wrote:
as a longer term point to consider, i think the current model of "best
effort at most once" was the wrong design point - if we embraced failure
and just retried (at least once), then failure at this level would lead to
retries which is reasonable.
if we added a third health route or introduced a health check, would we
increase the critical path?
-r
On Tue, Oct 29, 2019 at 12:29 PM David P Grove <gro...@us.ibm.com> wrote:
> Tyson Norris <tnor...@adobe.com.INVALID> wrote on 10/28/2019 11:17:50 AM:
> > I'm curious to know what other
> > folks think about "generic active probing from invoker" vs "docker/
> > mesos/k8s specific integrations for reacting to container failures"?
> >
>
> From a pure maintenance and testing perspective I think a single common
> mechanism would be best if we can do it with acceptable runtime overhead.
>
> --dave
>
