mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <vinodk...@gmail.com>
Subject Re: Review Request 58195: Added TCP checks in Mesos API.
Date Thu, 13 Apr 2017 01:03:03 GMT


> On April 7, 2017, 1:09 a.m., Vinod Kone wrote:
> > include/mesos/mesos.proto
> > Lines 1773 (patched)
> > <https://reviews.apache.org/r/58195/diff/1/?file=1684601#file1684601line1773>
> >
> >     `succeeded` seems a bit weird, can we call it `status` or `connection_status`
to be consistent?
> >     
> >     Also, is `boolean` enough to represent the TCP connection status? Looks like
a TCP connection can be in a few different  stateshttps://doc.nexthink.com/Documentation/Nexthink/V5.3/GlossaryAndReferences/StatusofTCPconnections
?
> 
> Alexander Rukletsov wrote:
>     I don't think `status==true` is good either, hence I went with `succeeded==true`,
because it _reads good_. Let's look at other bool field in mesos.proto:
>     `TaskStatus.healthy` `==true` — sounds good
>     `Image.Docker.cached` `==true` — sounds good
>     `ContainerInfo.DockerInfo.privileged` `==true` sounds good
>     `ContainerInfo.DockerInfo.force_pull_image` `==true` sounds good
>     `FrameworkInfo.checkpoint` `==true` sounds good
>     `CommandInfo.executable` `==true` sounds good
>     `CommandInfo.extract` `==true` sounds good
>     `CommandInfo.shell` `==true` sounds good
>     
>     Regarding multiple states. I don't think we care what we get for our `SYN` request,
unless it is `SYN-ACK`, in which case TCP check is considered successful. Using the document
you provide:
>     `established`: means TCP check succeeds
>     `closed`: same, implies TCP handshake was successful => TCP checks succeeds
>     `no service`: `RST` as response, i.e. no `SYN-ACK` => handshake fails => TCP
check fails
>     `no host`: no responce, i.e. no `SYN-ACK` => handshake times out => TCP check
fails
>     `rejected`: no `SYN-ACK` => handshake fails => TCP check fails
>     
>     If in the future we want to distinguish timeout handshakes, we probably should do
it globally for all types of checks.

I don't know if it makes sense to compare other boolean fields in the proto file. They are
captuing different concepts or semantics.

What I was mainly looking for was consistency within the `CheckStatusInfo` proto itself because
it's capturing the `status` of different kinds of checks. We have `exit_code` (for command),
`status_code` (for HTTP) and `succeeded` (for TCP). The last seemed inconsistent with the
first two.

But I don't have a good suggestion for an alternative. So I'm ok `succeeded`.


- Vinod


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


On April 4, 2017, 10:24 p.m., Alexander Rukletsov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58195/
> -----------------------------------------------------------
> 
> (Updated April 4, 2017, 10:24 p.m.)
> 
> 
> Review request for mesos, Gastón Kleiman and Vinod Kone.
> 
> 
> Bugs: MESOS-7275
>     https://issues.apache.org/jira/browse/MESOS-7275
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> From now on executors may implement TCP checks for tasks.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto dd90465cc3da283c078d4e907cc6a4a0e50309ac 
>   include/mesos/v1/mesos.proto 82d020e05b303a8248a90bc482b76b54b335146c 
>   src/checks/checker.cpp 7510bf23977e007d101fab635865b7160c3a5af6 
>   src/common/type_utils.cpp dc0dd71f52581e2067fed279677bda8c82aa7298 
>   src/launcher/default_executor.cpp 9cc40c6391a931f9cdf6965e64be231980537299 
>   src/launcher/executor.cpp bc69beb884d95d1616b2a3d928cdbf00f70f7c88 
>   src/tests/check_tests.cpp d7fcbf940102efe0841f07e8c4937a78361bc422 
>   src/v1/mesos.cpp 5605ff22da77724a7947637bc17e12143ee34802 
> 
> 
> Diff: https://reviews.apache.org/r/58195/diff/1/
> 
> 
> Testing
> -------
> 
> See https://reviews.apache.org/r/58196/
> 
> 
> Thanks,
> 
> Alexander Rukletsov
> 
>


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