[ 
https://issues.apache.org/jira/browse/MESOS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217367#comment-14217367
 ] 

Timothy Chen commented on MESOS-2120:
-------------------------------------

Hi Ben, let me see if I can answer some
Of these questions:

1, frameworks should use labels when you want to search for tasks for certain 
labels. 
The labels field is really meant for metadata of tasks, that we can provide end 
points to query these metadata. Data is really just meant for the execution of 
the task.

3, it's true that the active tasks can grow unbounded, we don't have a size 
limit in place yet but it is most likely we need a per task limit how much 
label data can it allow, which I can imagine this can be configurable too.

I think we didn't include this yet, if you agree this is a good approach we can 
create a new jira

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

Reply via email to