mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiang Yan Xu <xuj...@apple.com>
Subject Re: Review Request 55453: Updated comments in `HealthCheck` protobuf for clarity.
Date Wed, 01 Feb 2017 10:18:10 GMT


> On Jan. 30, 2017, 6:01 p.m., Jiang Yan Xu wrote:
> > include/mesos/mesos.proto, lines 424-426
> > <https://reviews.apache.org/r/55453/diff/4/?file=1610587#file1610587line424>
> >
> >     The most direct interpretation for the delay is actually the time since the
task was launched right? AFAIK Mesos provided executors immediately send TASK_RUNNING but
this is not generally required right?
> 
> Alexander Rukletsov wrote:
>     What do you understand under launch. Is it when the task has been submitted to the
master? Or when a scheduler got `TASK_STAGING`? Or all necessary artifacts have been fetched
and _executor_ launches the task? Built-in executors indeed send task running right after
they launched the task (and at the same time start the delay timer for checks or health checks).
Custom executors are out of our control, they may send updates later on.
>     
>     Since we cannot start the delay timer at `TASK_STAGING` or when the task is submitted
to the master, we can either agree on `TASK_RUNNING` or "task has been submitted to the executor".
I think the latter event is vague and hence suggested to tie the delay to `TASK_RUNNING`.
For built-in executors both events occur close to each other in time.
> 
> Robert Lacroix wrote:
>     I would say it should start after `TASK_STARTING`. For years we have been using the
following semantic:
>     
>     `TASK_STARTING`: The executor launched the task
>     `TASK_RUNNING`: The task is ready to receive production traffic (i.e. passing health
checks if there are any defined. If there aren't health checks defined it's being sent right
after `TASK_STARTING`).
>     
>     If delay_seconds only starts after `TASK_RUNNING` this semantic doesn't make sense
anymore. If that's the case, I'm not sure why we even have a distinction between `TASK_RUNNING`
and `TASK_STARTING`?
> 
> Alexander Rukletsov wrote:
>     I see, good point. Build-in executors do not send `TASK_STARTING` so we can agree
that the delay timer starts right after `TASK_STARTING`.

Sorry I overlooked this conversation. By "launch" I meant the moment when the executor "launches"
it (by fork-execing, launching nested container or simply calling a function). Since `TASK_STARTING`
is not a required state I wouldn't use it to defined "launch" in general but one can certainly
associate `TASK_STARTING` with this action.


- Jiang Yan


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


On Jan. 20, 2017, 6:48 a.m., Alexander Rukletsov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55453/
> -----------------------------------------------------------
> 
> (Updated Jan. 20, 2017, 6:48 a.m.)
> 
> 
> Review request for mesos, Gastón Kleiman, haosdent huang, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 8f14444d6957a97eff1e0a94817d38e7a7de6d69 
>   include/mesos/v1/mesos.proto 74e7851b147ab821dceeab6e838d34b092f101c3 
> 
> Diff: https://reviews.apache.org/r/55453/diff/
> 
> 
> Testing
> -------
> 
> None: not a functional change.
> 
> 
> Thanks,
> 
> Alexander Rukletsov
> 
>


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