Re: Review Request 55453: Updated comments in `HealthCheck` protobuf for clarity.

[Jiang Yan Xu <xu...@apple.com>]

> 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
> 
>