[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175065#comment-15175065
]
Guangya Liu commented on MESOS-4816:
1) When Kubernetes framework register, it will create a executor
https://github.com/kubernetes/kubernetes/blob/master/contrib/mesos/pkg/scheduler/service/service.go#L492-L499
2) Then kubernetes will use this executor to launchtask.
https://github.com/kubernetes/kubernetes/blob/master/contrib/mesos/pkg/scheduler/podtask/pod_task.go#L191-L198
So the executor will be launched with the first task and later on, all tasks
wil this executor and this caused the isolator cannot get other task infos.
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175016#comment-15175016
]
James Peach commented on MESOS-4816:
{quote}
it will not work for some cases such as Kubernetes and Mesos integration where
one executor can manage many tasks.
{quote}
How does this work in Kubernetes? Can you point me to code or something?
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174848#comment-15174848
]
Guangya Liu commented on MESOS-4816:
I saw that MESOS-4500 enabled {{Expose ExecutorInfo and TaskInfo for isolators
in prepare()}}, but as [~cdoyle] point out, this is not enough, as {{prepare}}
wil only be invoked just once per container executor, it will not work for some
cases such as Kubernetes and Mesos integration where one executor can manage
many tasks.
Does it make sense to leave this ticket and update the isoloator api of
{{update()}} to pass a list of {{TaskInfo}} to cover more cases?
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174232#comment-15174232
]
Connor Doyle commented on MESOS-4816:
-
Thanks for the update James, my experience with this is also pre-0.28. As I
understand it, {{prepare()}} gets invoked just once per container (for an
executor's first task), so it might not be sufficient given a framework that
launches multiple tasks per executor. However, if {{ContainerConfig}} covers
most uses then maybe this issue can be dropped?
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174136#comment-15174136
]
James Peach commented on MESOS-4816:
The isolator that I have that consumes {{TaskInfo}} labels was written for
Mesos 0.27. Since 0.28, {{prepare()}} gets a {{ContainerConfig}} which looks
like it should have the {{TaskInfo}}.
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174099#comment-15174099
]
Connor Doyle commented on MESOS-4816:
-
Hi [~gyliu],
I agree the optional task info argument in the comment is awkward, but a list
sounds pretty good. Existing isolators could continue to look only at the
aggregated resources.
This question came up during the isolation WG meeting last week. I and others
have used this workaround while prototyping isolators for networking, but in
general people tend to pass information to isolators via task labels before
concepts become first-class in ContainerInfo or elsewhere. [~jamespeach] and
[~idownes] may be able to fill in more details.
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173399#comment-15173399
]
Guangya Liu commented on MESOS-4816:
[~cdoyle] Can you please show a concrete use case for this? When the isolator
want to access the TaskInfo? Does the isolator want to access all task infos?
The problem with your proposal is that the {{update}} is mainly used to update
executor resources when task/executor is running, and one executor container
will map to multiple tasks but not one task. so the parameter here for
{{TaskInfo}} may need to be a list?
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4816) Expose TaskInfo to Isolators
[
https://issues.apache.org/jira/browse/MESOS-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172432#comment-15172432
]
Connor Doyle commented on MESOS-4816:
-
Maybe the {{update}} signature could be expanded like this?
{code:title=include/mesos/slave/isolator.hpp|borderStyle=solid}
// Update the resources allocated to the container.
virtual process::Future update(
const ContainerID& containerId,
const Resources& resources,
const Option& taskInfo) = 0;
{code}
> Expose TaskInfo to Isolators
>
>
> Key: MESOS-4816
> URL: https://issues.apache.org/jira/browse/MESOS-4816
> Project: Mesos
> Issue Type: Improvement
> Components: modules, slave
>Reporter: Connor Doyle
>
> Authors of custom isolator modules frequently require access to the TaskInfo
> in order to read custom metadata in task labels.
> Currently, it's possible to link containers to tasks within a module by
> implementing both an isolator and the {{slaveRunTaskLabelDecorator}} hook,
> and maintaining a shared map of containers to tasks. This way works, but
> adds unnecessary complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
