[
https://issues.apache.org/jira/browse/MESOS-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033048#comment-14033048
]
Benjamin Hindman commented on MESOS-741:
----------------------------------------
Outputting multiple things is not a problem with the "recordio" format. It is
true that mesos-usage just outputs one thing, but the "recordio" format enables
multiple things to be output easily. Note that to output in "recordio" you'd
use protobuf::write() and it isn't JSON that's getting written but the actual
serialized protobuf. Outputting JSON is an option that can be used, however,
likely just for human consumption.
On the receiving side you can just use protobuf::read() to capture the stream
of protobufs coming from mesos-health-checker (no need to write any special
handling code). This is exactly how Till did the external containerizer as
well, so it's a pattern that I think would be nice to keep consistent with
subprocess utilities, but we can always circle back to this later.
> Add health checking for tasks
> -----------------------------
>
> Key: MESOS-741
> URL: https://issues.apache.org/jira/browse/MESOS-741
> Project: Mesos
> Issue Type: Story
> Components: master, slave
> Reporter: Niklas Quarfot Nielsen
> Assignee: Timothy Chen
>
> Determining the health of a task during its lifetime (during start up, while
> it is running, shutting down etc.) can be considered a more elaborate matter
> than only observing its process state.
> The task health might be determined by any combination of observable
> behavior; for example the process being listening to a certain range of
> ports, writing certain files or pipes, responding to messages, utilizing
> resources to or below certain thresholds etc.
> It could be a powerful extension to extend the interface for launching and
> running tasks by an optional HealthCommand message. This message could encode:
> 1) A command to be run at the slave to determine the health of the task. The
> return value of the command will tell if the task is healthy or unhealthy.
> 2) An interval which to run the health command.
> In connection with this, it could make sense to introduce new healthy and
> unhealthy task states.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
