[
https://issues.apache.org/jira/browse/MESOS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221642#comment-14221642
]
Niklas Quarfot Nielsen commented on MESOS-2120:
-----------------------------------------------
It is a trade-off between completely unstructured data (in the data field) and
pre-defined protobufs which describe concept A, B and C which in my mind add a
lot of flexibility (downside being that different frameworks can choose
different labels - 'env' / 'environment').
The task-info has unbounded fields already (not an excuse for making it even
bigger). We can introduce a configurable max to bound the memory (for labels
and in general).
I will follow up with a review request with a more clear comment in the header,
describing what labels should/should not be used for.
> Add support for task labels / parameters
> ----------------------------------------
>
> Key: MESOS-2120
> URL: https://issues.apache.org/jira/browse/MESOS-2120
> Project: Mesos
> Issue Type: Task
> Reporter: Niklas Quarfot Nielsen
> Assignee: Niklas Quarfot Nielsen
> Priority: Minor
>
> Add support to hang key value pairs off tasks which follows them through the
> task life-cycle. This can be made available through the existing HTTP
> end-points (state, tasks and so on) which the data field cannot do, as we
> cannot make any assumptions in how to interpret the user data.
> A capability like this is a relative small change compared to the leverage it
> gives with regards to external tooling.
> We should consider the implications of the new field just like the data field
> with respect to avoid requiring excess memory to store the task info's.
> We already have a proto message for key value pairs called Parameter:
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L712
> So the suggested change is:
> {code}
> message TaskInfo {
> required string name = 1;
> required TaskID task_id = 2;
> required SlaveID slave_id = 3;
> repeated Resource resources = 4;
> optional ExecutorInfo executor = 5;
> optional CommandInfo command = 7;
> // Task provided with a container will launch the container as part
> // of this task paired with the task's CommandInfo.
> optional ContainerInfo container = 9;
> optional bytes data = 6;
> // A health check for the task (currently in *alpha* and initial
> // support will only be for TaskInfo's that have a CommandInfo).
> optional HealthCheck health_check = 8;
> optional Parameters parameters = 9;
> }
> {code}
> Alongside the necessary changes to expose the value in master and slave
> endpoints.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
