[
https://issues.apache.org/jira/browse/MESOS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217303#comment-14217303
]
Benjamin Mahler commented on MESOS-2120:
----------------------------------------
Interesting, what's the use-case?
Have a few questions:
# As a framework, when do I pass {{Parameters}}, and when do I pass {{data}}?
There are two ways to pass information in the task, which seems unfortunate. It
sounds like we'll need to provide some guidance in the protobuf definition, so
that frameworks' know how to use these! ;)
# Why can't a tool operate on the frameworks, as opposed to the master? That
is, what do we gain by pushing this functionality into mesos, when we cannot
ensure that frameworks use keys/values consistently? As an example, one
framework might use "prod", one might use "production", one might not set
parameters at all.
# We currently don't store "data" in memory for launched tasks, whereas the
suggestion here is to store parameters in memory. How will we prevent abuse, or
more importantly, scalability issues. For example, if I have 100,000 active
tasks, roughly how many bytes can each task use for parameters? How does it
play with the task history in the master? Could we enforce a size limit? My
concern is if we hit a memory limitation in the master, it's next to impossible
to make progress, which is pretty scary. Good monitoring is a must but curious
if we can have any defense here.
> 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)
