[
https://issues.apache.org/jira/browse/AURORA-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620942#comment-14620942
]
Renan DelValle commented on AURORA-1376:
----------------------------------------
[~jaybuff]], you make some great points.
The JSON schema comes from trying to simulate the ExecutorSettings data
structure in the Aurora Scheduler. As I've said previously, the schema is
subject to change, so I appreciate your suggestions.
Here are the reasons why ExecutorSettings, as it exists right now, is different
from ExecutorInfo:
a. The ExecutorSettings data struct uses the CommandUtil
(org/apache/aurora/scheduler/base/CommandUtil.java) wrapper to configure the
CommandInfo to fetch and execute given URIs for an executor. [~wfarner], is
this feature considered part of Aurora or part of Thermos?
b. It also stores info about global container mounts. which it uses when
creating docker containers.
If we create an interface, IMO, it should return a TaskInfo.Builder, as that
would spare us from having a special case for the mesos command executor. For
what it's worth, an early version of my code is here
https://reviews.apache.org/r/36289/. I've fixed all the errors that were caused
by my changes and will be putting up a new version up later on today.
As for having the client send in any info to configure the executor, we had a
discussion a short while ago and came to the conclusion, that amongst other
things, it is considered a security risk due to the fact that Aurora runs as
root
(https://issues.apache.org/jira/browse/AURORA-1288?focusedCommentId=14601470&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601470)
Thus, IMO, using a server-side config file is still the best option.
> Create support for custom executors in Scheduler
> ------------------------------------------------
>
> Key: AURORA-1376
> URL: https://issues.apache.org/jira/browse/AURORA-1376
> Project: Aurora
> Issue Type: Sub-task
> Components: Scheduler
> Reporter: Renan DelValle
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)