mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Chen (JIRA)" <>
Subject [jira] [Commented] (MESOS-2120) Add support for task labels / parameters
Date Wed, 19 Nov 2014 04:02:33 GMT


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

> Add support for task labels / parameters
> ----------------------------------------
>                 Key: MESOS-2120
>                 URL:
>             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:
> 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

View raw message