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