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