[ 
https://issues.apache.org/jira/browse/MESOS-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach reassigned MESOS-8018:
----------------------------------

    Assignee:     (was: James Peach)

> Allow framework to opt-in to forward executor's JWT token to the tasks
> ----------------------------------------------------------------------
>
>                 Key: MESOS-8018
>                 URL: https://issues.apache.org/jira/browse/MESOS-8018
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Zhitao Li
>            Priority: Major
>
> Nested container API is an awesome feature and enabled a lot of interesting 
> use cases. A pattern we have seen multiple times is that a task (often the 
> only one) launched by default executor wants to further creates containers 
> nested behind itself (or the executor) to run some different workload.
> Because the entire request is 1) completely local to the executor container, 
> 2) okay to be bounded within the executor's lifecycle, we'd like to allow the 
> task to use the mesos agent API directly to create these nested containers. 
> However, it creates a problem when we want to enable HTTP executor 
> authentication because the JWT auth tokens are only available to the executor 
> so the task's API request will be rejected.
> Requiring framework owner to fork or create a custom executor simply for this 
> purpose also seems a bit too heavy.
> My proposal is to allow framework to opt-in with some field so that the 
> launched task will receive certain environment variables from default 
> executor, so the task can "act upon" the executor. One idea is to add a new 
> field to allow certain environment variables to be forwarded from executor to 
> task.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to