[
https://issues.apache.org/jira/browse/MESOS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219966#comment-14219966
]
Benjamin Mahler commented on MESOS-2120:
----------------------------------------
{quote} 1, frameworks should use labels when you want to search for tasks for
certain labels. {quote}
[~tnachen] who is "you" in this context? Is it the operator? The assumption
here seems to be that labels will be used consistently across frameworks for
this to be leveraged. I think this is where I'm left a bit confused by this
API, it's hard to see how these will be used in a multi-framework scenario,
which is the entire premise of mesos! ;) Would love to hear some concrete use
cases. At the very least, we should have some examples or guidance in the
protobuf definition IMHO.
> 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)
