[
https://issues.apache.org/jira/browse/AURORA-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219610#comment-14219610
]
brian wickman commented on AURORA-915:
--------------------------------------
[~tomdunham] actually no -- it's mostly used to introspect the job key, e.g.
{noformat}
# -*- python -*-
# Default production Mesos cluster configuration.
import sys
include("defaults.aurora")
# Process
dc = sys.argv[4].split('/')[0]
environment = "staging"
...
{noformat}
Which is a terrible anti-pattern, for one since it ties you to a specific
version / invocation of the client, but also since this is usually available
via the {{\{\{cluster\}\}}} template.
As part of AURORA-188, I think it does make sense to make -E more clearly
supported. Right now it's sort of looked down upon since any context
introduced by -E is lost when the job is serialized on the client. There are
some mentions of how to not lose this context in AURORA-188.
> create strict mode for .aurora config
> -------------------------------------
>
> Key: AURORA-915
> URL: https://issues.apache.org/jira/browse/AURORA-915
> Project: Aurora
> Issue Type: Task
> Components: Client
> Reporter: brian wickman
>
> I propose we have a strict mode for .aurora configuration (pystachio) that
> prevents importing python modules (including os and sys.) Possibly we
> snapshot os.environ and provide a binding helper to give access to it. For
> people who need things like the current user, perhaps provide a default
> binding like {{\{\{system.user\}\}}} and the like. We are getting bitten by
> people adding too much sophistication into .aurora configuration like full
> blown sys.args introspection and web clients, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
